OAuth2.1の差分を見守る会: draft 09-10
本投稿は OAuth 2.1 って呼ばれたい感を出してる仕様の差分を見守る会です。
本投稿含め、差分を スクラップ - OAuth 2.1を見守る会 でまとめています。
差分
draft10 における主な差分は、Appendix E. Document History に記載の以下の通りです。
一見変更点が多そうです。念のため上から見ていきましょう。なお、当方の主観で対応する変更を記載していますが、認識が間違っている可能性は十分あります。もし、認識間違っている箇所があれば GitHub から Issue また PR を作成してご指摘いただけますと幸いです。
- Clarify that the client id is an opaque string
- Extensions may define additional error codes on a resource request
- Improved formatting for error field definitions
- Moved and expanded "scope" definition to introduction section
- Split access token section into structure and request
- Renamed b64token to token68 for consistency with RFC7235
- Restored content from old appendix B about application/x-www-form-urlencoded
- Clarified that clients must not parse access tokens
- Expanded text around when redirect_uri parameter is required in the authorization request
- Changed "permissions" to "privileges" in refresh token section for consistency
- Consolidated authorization code flow security considerations
- Clarified authorization code reuse - an authorization code can only obtain an access token once
Clarify that the client id is an opaque string
Client ID は opaque であることが明記されました。Client 作成時の入力として Client ID を指定可能な Authorization Server も存在しているような気がしますが今度どういった扱いになるのでしょう。
Extensions may define additional error codes on a resource request
拡張仕様において追加のエラーが定義される場合があることが記載されました。
Improved formatting for error field definitions
"3. Protocol Endpoints" や "5. Resource Requests" の "Error Response" におけるいくつかのフィールドの説明が増えている気がします。
Moved and expanded "scope" definition to introduction section
まず、"scope" の定義が "1. Introduction" セクションに移動しました。
また、scope によるアクセス許可のメカニズムあたりの説明や例などが増えているように見受けられます。
Split access token section into structure and request
Access Token に関するセクションが分割されたとのことです。
確かに、"1.4. Access Token"、"5. Resource Requests" といった形式で章が分割され、内容も一部追記されているようです。
Renamed b64token to token68 for consistency with RFC7235
"b64token" という用語が使用されていた箇所が "token68" に変更されました。
確かに "RFC 7235 Hypertext Transfer Protocol (HTTP/1.1): Authentication" では "b64token" という用語は出てこず "token68" という用語が使用されています。
Restored content from old appendix B about application/x-www-form-urlencoded
Appendix B の内容が TBD になっていましたがリストアされたようです。GitHub Issue での議論は継続されています。
Clarified that clients must not parse access tokens
Client は Access Token を解析してはならないことが明記されました。
なぜ Client が Access Token を解析してはダメなのかというのはトークンのオーディンエスの概念と併せて理解することができると思います。
トークンのオーディエンスの概念については、個人的に最近見たコンテンツの中だと以下の動画がわかりやすいと思いました。
JWT 形式の Access Token の利用も増えてきているためここら辺の概念を再確認しておくと良いかもしれないですね。
Expanded text around when redirect_uri parameter is required in the authorization request
Authorization Request で redirect_uri パラメーターが必要な場合だけでなく必要でない場合の説明が追記されました。
Changed "permissions" to "privileges" in refresh token section for consistency
"1.3.2. Refresh Token" において "permissions" という用語が "privileges" に置き換えられました。
Consolidated authorization code flow security considerations
Authorization Code に関する Security Considerations が "7.5. Authorization Code Security Considerations" として纏められて探しやすくなりました。
Clarified authorization code reuse - an authorization code can only obtain an access token once
"7.5.3. Reuse of Authorization Codes" という章が追記されて Authorization Code の再利用について明記されました。
ひとつの Authorization Code を使用して Access Token を取得できるのは一度だけであり、Authorization Code を再利用した場合は Token Request を拒否しつつ発行されたトークンを失効させることで防ぐことができる被害などについての記載があります。一方で Authorization Code および当該 Authorization Code を使用して発行された Access Token の記録やリクエストに応じた Access Token の失効処理が必要になり実装が複雑になることも想定されます。
おわり
新規のセクションの追加は少なめでしたが、仕様として明記してもらえると誰かが助かるような内容の追記が複数おこなわれているような印象でした。
なお、個人的にはだいぶタイムリーな話題がおおくて興味深い変更でした。
(例えば、割と最近 Identity Dance School の Discord でトークンのオーディエンスの疑問について投げかけさせてもらったり、GitHub Issue で議論されているようなエンコーディングに関するバグを踏んだりしていました。)
ではまた！
Discussion