OAuth 2.1の差分を見守る会 : draft 04-05

本投稿はOAuth 2.1って呼ばれたい感を出してる仕様の差分を見守る会です。

本投稿含め、差分を スクラップ - OAuth 2.1を見守る会 でまとめています。

差分

差分

draft 05 における主な差分としては、Appendix E. Document Historyに記載の以下の通りです。

• Added a section about the removal of the implicit flow

• Moved many normative requirements from security considerations
  into the appropriate inline sections

• Reorganized and consolidated TLS language

• Require TLS on redirect URIs except for localhost/custom URL
  scheme

• Updated refresh token guidance to match security BCP

変更差分の全体を見ると多くの差分があるように見えますが、Security Considerations などの章から適切な章に説明が移動したことに伴うものが多いです。その他にも TLS やリフレッシュトークンに関する表現の細かい修正などが含まれます。
draft 05 における最も大きな変更は、「10.1. Removal of the OAuth 2.0 Implicit grant」という章の追加になりそうです。次いで、「Require TLS on redirect URIs except for localhost/custom URL scheme」でしょうか。
本投稿では、上記の内容を抑えつつ、その他の細かい変更点についても、ざっくりと確認していきます。

目次

目次における主な差分としては以下の通りでした。なお、「10.1. Removal of the OAuth 2.0 Implicit grant」を除き、完全に新規で追加された章はなさそうでした。一見新規で追加されたように見える章も、元々別の章にて記載されていた内容を抜き出しているだけのようでした。

• TLS Version -> Communication security (変更)
• Endpoint Request Confidentiality (削除)
• Preventing CSRF Attacks (追加)
• Preventing Mix-Up Attacks (追加)
• Refresh Tokens (削除)
• Request Confidentiality (削除)
• Removal of the OAuth 2.0 Implicit grant (追加)
• Security Considerations in Native Apps (追加)

1.5. Communication security

章のタイトルが「TLS Version」から「Communication security」に変わっています。
内容に関しては、draft 04 の「1.5. TLS Version」では、適切なバージョンの TLS をいつでも利用することが要件として記載されていましたが、「Communication security」では、TLS に限定しないような記載に表現が変更されています。

Implementations MUST use a mechanism to provide communication authentication, integrity and confidentiality such as Transport-Layer Security [RFC8446], to protect the exchange of clear-text credentials and tokens either in the payload body or in header fields from eavesdropping, tampering, and message forgery (eg. see Section 2.4.1, Section 7.6, Section 3.2, and Section 5.2).

なお、ループバックインターフェースのリダイレクト URI は例外として http スキームを利用しても良いとの記載が追加されています。

OAuth URLs MUST use the https scheme except for loopback interface redirect URIs, which MAY use the http scheme.

また、TLS のバージョンおよび利用されるアルゴリズムはこの仕様の範囲外であることが明記されました。

The identification of the TLS versions and algorithms is outside the scope of this specification.

3.1. Authorization Endpoint

以下の認可エンドポイントにおける要件は draft 05 にて新しく追記されたもののようです。認可サーバーは、ユーザーのクレデンシャルを含む可能性があるリクエストをリダイレクトする場合、誤ってユーザーのクレデンシャルを転送することを避けなければならない (MUST)　とのことです。

An authorization server that redirects a request potentially containing user credentials MUST avoid forwarding these user credentials accidentally (see Section 7.5.2 for details).

4.1.3. Token Endpoint Extension

redirect_uri の検証について、認可リクエストに redirect_uri が含まれていなかった場合に、redirect_uri パラメーターは OPTIONAL になることが追記されました。

"redirect_uri": REQUIRED, if the redirect_uri parameter was included in the authorization request as described in Section 4.1.1, and in which case their values MUST be identical. If no redirect_uri was included in the authorization request, this parameter is OPTIONAL.

4.3. Refresh Token Grant

draft 04 の「7.5. Refresh Tokens」に記載されていた内容がこの章に記載されるようになっていますが、内容自体の差分は表現が微妙に違うくらいに見受けられました。なお、その他の章の差分を確認してもリフレッシュトークンの説明に関するコレといった差分は見受けられず、「Updated refresh token guidance to match security BCP」とはどの部分を指しているのか不明です。

5.2. Bearer Tokens

draft 04 の「7.1.2. Threat Mitigation」や「1.4. Access Token」に記載されていた一部の内容について、表現が変更されつつ、内容も追記され、「5.2. Bearer Tokens」に記載されるようになっていました。
アクセストークンがランダム文字列の場合の要件および、JWT などの形式にエンコードされた場合の要件がそれぞれ記載されています。

There is no requirement on the particular structure or format of a bearer token, as described in Section 5. If a bearer token is a reference to authorization information, such references MUST be infeasible for an attacker to guess, such as using a sufficiently long cryptographically random string. If a bearer token uses an encoding mechanism to contain the authorization information in the token itself, the access token MUST use integrity protection sufficient to prevent the token from being modified. One example of an encoding and signing mechanism for access tokens is described in JSON Web Token Profile for Access Tokens [RFC9068].

10.1. Removal of the OAuth 2.0 Implicit grant

draft 05 にて新しく追記された章です。

以前より「10. Differences from OAuth 2.0」にて、OAuth 2.0 の Implicit Grant は OAuth2.1 では省かれると記載されていましたが、この章においても明記されるようになりました。

The OAuth 2.0 Implicit grant is omitted from OAuth 2.1 as it was deprecated in [I-D.ietf-oauth-security-topics].

また、OAuth 2.1 にて Implicit Grant を削除する目的が以下の通り記載されました。具体例として、トークンの漏洩やインジェクションに対して脆弱であることや、トークンを sender-constrained として扱えないことが記載されています。

The intent of removing the Implicit grant is to no longer issue access tokens in the authorization response, as such tokens are vulnerable to leakage and injection, and are unable to be sender-constrained to a client. This behavior was indicated by clients using the response_type=token parameter. This value for the response_type parameter is no longer defined in OAuth 2.1.

最後に "response_type=token" の削除は、OpenID Connect で定義された "response_type=id_token" などの拡張に対して影響しないことが記載されています。

Removal of response_type=token does not have an effect on other extension response types returning other artifacts from the authorization endpoint, for example, response_type=id_token defined by [OpenID].

終わり

今回は差分がたくさんあるように見えて、実はほとんど記載される章が変わっただけみたいな感じでした。
ではまた！