OAuth 2.1の差分を見守る会 : draft 08-09
ritou です。
本投稿はOAuth 2.1って呼ばれたい感を出してる仕様の差分を見守る会です。
本投稿含め、差分を スクラップ - OAuth 2.1を見守る会 でまとめています。
2023/7/10にドラフト09が出ています。
08との差分からどんな部分が強調されたり説明が追加されたのかなというのを見ていきます。
-09
- AS MUST NOT support CORS requests at authorization endpoint
- more detail on asymmetric client authentication
- sync CSRF description from security BCP
- update and move sender-constrained access tokens section
- sync client impersonating resource owner with security BCP
- add reference to authorization request from redirect URI registration section
- sync refresh rotation section from security BCP
- sync redirect URI matching text from security BCP
- updated references to RAR (RFC9396)
- clarifications on URIs
- removed redirect_uri from the token request
- expanded security considerations around code_verifier
- revised introduction section
結構ありますね。見ていきましょう。
AS MUST NOT support CORS requests at authorization endpoint
Authorization Endpointはブラウザのリダイレクトで使われるものなので、CORSをサポートしてはいけません。
more detail on asymmetric client authentication
Private Key JWTの説明が細かくなっています。
ユーザー認証ではパスワード自体を送らない、OAuthのクライアント認証でもClient Secretを送らないのが常識になると安全な世の中になるでしょう。
sync CSRF description from security BCP
はい
update and move sender-constrained access tokens section
7.1から5.4に移動と。
DPoPへの言及も見られますね。 あれいつRFCになるんや。
sync client impersonating resource owner with security BCP
Cient Credentialsで取得したATとAuthZ Codeとかで取得したATをちゃんと区別しておかないとなりすましが行われる可能性があるということですね。よく考えて実装しましょう。
add reference to authorization request from redirect URI registration section
sync refresh rotation section from security BCP
rotationに関する文言は変更されていない気がしますね。関連しそうなのはこのあたりでしょうか。
sync redirect URI matching text from security BCP
updated references to RAR (RFC9396)
clarifications on URIs
これはよくわからんけどまぁ良さそう。
removed redirect_uri from the token request
認可コードインジェクション対策として利用されてきた redirect_uri ですが、PKCEによる対策を想定している OAuth 2.1では意味がないので要りませんということです。
当然、OAuth 2.0との互換性がなくなるわけなので、下位互換を保証するかどうかで挙動が変わることに注意しましょう。
expanded security considerations around code_verifier
この辺ですかね。
PKCE使っていきましょう。
revised introduction section
"OAuth introduces an authorization layer to..." というOAuthの概要は、次の差分からのお引越しですね。
次の差分が新しいところです。
2つの段落のうち、前者はポリシー評価についてですね。
レガシーなクライアント認証ありのリクエストの場合はそこからRSが本当に認可を得ているかのポリシー評価もしないといけないし分散システムだとポリシーの同期も必要になりまが、OAuthにおいてポリシー評価を行うタイミングはAT発行時なので、RSはポリシーを意識しないでATの検証だけで良いですよと。
とはいえ、この先のお話としてこれで不十分なケースってのがあります。
リクエスト元のIPアドレスがポリシー評価に含まれる場合、 リソースアクセス時に変更されているかもしれないと。そのような場合への対策としてCAE(Continuous Access Evaluation)があり、そこで使われるプロトコルがOpenID CAEP(OpenID Continuous Access Evaluation Profile)です。
そして後者は、いわゆる OAuth認証 についての言及ですね。
プロフィールAPIの結果をユーザー認証に利用する方法はOAuthの仕様や Security Considerations に含まれておらず、ROも「プロフィールAPIにアクセスする」ことには同意しても「このサービスにログインします」まで意識されないかもしれません。その辺りから実装者はよく考えてね、という優しい表現ではありますがOAuth認証に触れてもらっただけで私は喜びを感じています。
まとめ
この段階で大きな変更きてもたまらんのですが、細かい記述の整理が多かった印象でした。
今回の差分で注目すべき点、あえて言うならAccess Token Requestのredirect_uriの扱いとIntroductionの更新あたりですかね。
OAuth認証をやめろ！
ではまた！
Discussion