Skip to content

Instantly share code, notes, and snippets.

@pinzolo

pinzolo/diff-oauth-v21-v20.md

Last active November 12, 2020 15:08
Show Gist options
  • Save pinzolo/732c3fe3c0c1a0ae0fefc47bac40791d to your computer and use it in GitHub Desktop.
Save pinzolo/732c3fe3c0c1a0ae0fefc47bac40791d to your computer and use it in GitHub Desktop.
Download ZIP
OAuth v2.1 と OAuth v2.0 の diff をとってみた
Raw
diff-oauth-v21-v20.md

The OAuth 2.1 Authorization Framework

Abstract

This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749.

OAuth 2.0 を置き換えるもので、従来の OAuth 2.0 は廃止となる

1. Introduction

HTTPの定義元 RFC が RFC2616 から RFC7230 に変更になった

  • OAuth 2.0 for Native Apps ([RFC8252])
  • OAuth Security Best Current Practice ([I-D.ietf-oauth-security-topics])
  • OAuth 2.0 for Browser-Based Apps ([I-D.ietf-oauth-browser-based-apps])

などの更新された情報を統合し、安全でない機能を削除した

1.1. Roles

  • リソースオーナーを RO. リソースサーバーを RS, 認可サーバーを AS とった略称の言及が追加されている
  • リソースサーバと認可サーバ間の相互運用性のための拡張が定義されている旨の文言が追加されている。

1.2. Protocol Flow

特に変更無し

1.3. Authorization Grant

Implicit と Resource Owner Password Credentials は削除

1.3.1. Authorization Code

ユーザーエージェントの定義先が RFC2616 から RFC7231 に変更になっている

1.3.2. Client Credentials

特に変更無し

1.4. Access Token

  • 構造的トークンの例として JWT への言及がある
  • 追加の認証資格情報の例として sender-constrained トークンが上がっており、さらにその例として MTLS への参照がある
  • RFC6750 への参照がなくなっている。Bearer 以外の方法が増えたし、Bearer はこのこのドキュメントで触れている

1.5. Refresh Token

  • 2: refresh token が optionaly ではなくなっている。refresh token の項だからか？
  • 7: ちょっと文言が変わっているだけ。内容は同じ

1.6. TLS Version

TLS の最新バージョンが更新されている

1.7. HTTP Redirections

リダイレクト時の HTTP Status code に 307 を使うなと追記されている

1.8. Interoperability

さまざまな拡張へのポインタが追加された

2. Client Registration

RFC7591 OAuth 2.0 Dynamic Client Registration Protocol への言及が追加

2.1. Client Types

  • client_id と client_secret に対する言及がある
  • client type に credentialed が増えて3つになった
    • confidential: クレデンシャルを持ち、認可サーバに身元が確認されたクライアント
    • credentialed: クレデンシャルを持つが、認可サーバに身元が確認されていないクライアント
    • public: クレデンシャルを持たないクライアント
  • 認可サーバはクライアントの身元に対する信頼度を考慮すべき
  • 1つの client_id を複数のクライアントタイプとして扱ってはならない。これは表現がシンプルになっただけっぽい
  • web application が confidential のままだけどここは credentialed じゃないとあかんのじゃない？
  • user-agent-based-application が browser-based-application になってる

2.2. Client Identifier

認可サーバはクライアントが client_id を選択したりすることを許可すべきでない。が追加。推測されるような client_id 作るなよってことか

2.3. Client Authentication

  • 認可サーバは可能ならばクライアント認証を行うべきという文が追加
  • クライアント認証は公開鍵ベースの方法を推奨する文が追加。mTLS と private_key_jwt を例に挙げている

2.3.1. Client Password

  • クライアントパスワードとはクライアントシークレットのことだよと説明が追記
  • クライアントシークレットが空の文字列なら client_secret パラメータは送らなくて良いの文言が消えている

2.3.2. Other Authentication Methods

OAuth Token Endpoint Authentication Methods へのリンクが追加

2.4. Unregistered Clients

変更なし

3. Protocol Endpoints

変更なし

3.1. Authorization Endpoint

  • HTTP GET メソッドの定義元 RFC が RFC2616 から RFC7231 に変更になった
  • 以下の3つの要件が追加
    • 認可サーバは値のないパラメータは省略されたように扱わなければならない
    • 認可サーバは認識されていないパラメータは無視しなければならない
    • リクエストパラメータとレスポンスパラメータは2回以上含めてはならない

3.1.1. Response Type

Implict Grant に関する記述が削除されている

3.1.2. Redirection Endpoint

リダイレクト先がクライアント登録時に登録したものに限定され、「もしくは認可リクエストに指定されたもの」の記述が削除された

「認可サーバはリダイレクトURIの比較を完全一致で行わなければならない」が追加

3.1.2.1. Endpoint Request Confidentiality

TLS を必須としていない理由が削除された（TLSが必須になったわけではない）

3.1.2.2. Registration Requirements
  • リダイレクトURI登録の要求が SHOULD から MUST に
  • 1つ以上の完全なリダイレクトURIのみを要求するようになった
3.1.2.3. Dynamic Configuration

認可リクエストに redirect_uri パラメータが含まれており、リダイレクトURIが事前に登録されていた場合の箇所が削除された

これは redirect_uri がリクエストパラメータに含まれていたときとして残しておいても良かったんじゃないか？

3.1.2.4. Invalid Endpoint

変更なし

3.1.2.5. Endpoint Content

クレデンシャルの例として認可コードが挙げられている

3.2. Token Endpoint

  • Implicit Grant に関する記述が削除された
  • RFC8414 OAuth 2.0 Authorization Server Metadata でトークンエンドポイントのURIがわかることが追加された
  • この仕様で定義された パラメータは二回以上含まれてはならないと限定的になった。Authorization Endpoint では限定されていなかったのは漏れなのか意図的なのか

3.2.1. Client Authentication

  • クレデンシャルを持つクライアントという表現が Confidential or credentialed に変更になった
  • 完全なリダイレクトURIが登録されていない場合という部分が削除（完全なリダイレクトURIがMUSTになったから不要になった）
  • 「トークンリクエストに client_id パラメータを含めても良い」という記述がなくなった。Authorization Code Grant と Client Credential Grant ではどちらも client_id を送信するためこの要件は不要になったのだろう

3.3. Access Token Scope

変更なし

4. Obtaining Authorization

Implict Grant と Resource Owner Password Credential Grant に関する記述が削除。内容は同じ

4.1. Authorization Code Grant

PKCE がデフォルトで組み込まれた

4.1.1. Authorization Request

大きく構成が変わり PKCE の説明が入っている。特定の条件下（Section 9.8.）でない限り PKCE は MUST

4.1.1.1. Client Creates a Code Verifier

code_verifier の作り方。RFC 7636 - Section 4.1. と同じ

4.1.1.2. Client Creates the Code Challenge

code_challenge の作り方。基本的には RFC 7636 - Section 4.2. と同じ

"plain" しかサポートしていないかどうかは RFC 8414 - OAuth 2.0 Authorization Server Metadata を見ればわかるという言及が追加

4.1.1.3. Client Initiates the Authorization Request

従来の 4.1.1. Authorization Request の内容がここに記載されている

  • PKCE のパラメータである code_challenge, code_challenge_method が追加
  • state が RECOMMENDED から OPTIONAL になっている。これは PKCE でも CSRF 対策になるからだと思う

4.1.2. Authorization Response

PKCE に関する文章が追加。RFC7636 - Section 4.4. と同じ内容が追加されている。

4.1.2.1. Error Response
  • 認可サーバは public クライアントからの code_challenge のないリクエストは拒否しなければならず、特定の条件（Section 9.8.）でないかぎり public 以外のクライアントでも拒否しなければならない
  • リクエストされた code_challenge_method をサポートしていないときのエラーについて。これも RFC7636 - Section 4.4.1. から

4.1.3. Access Token Request

  • PKCE の code_verifier がパラメータに追加された
  • PKCE 関連の検証処理が追加された

4.1.4. Access Token Response

変更なし

4.2. Client Credentials Grant

変更なし

4.2.1. Authorization Request and Response

変更なし

4.2.2. Access Token Request

変更なし

4.2.3. Access Token Response

変更なし

4.3. Extension Grants

例が SAML から RFC 8628 - OAuth 2.0 Device Authorization Grant に変わった

5. Issuing an Access Token

変更なし

5.1. Successful Response

  • application/json メディアタイプの定義元が RFC4627 から RFC7159 に変更された
  • Cache-Control や Pragma レスポンスヘッダフィールドの定義元が RFC2616 から RFC7234 に変更された
  • サンプル内の token_type が example から Bearer に変更になった。むしろなぜ example だったのか

5.2. Error Response

  • KCE 関連のパラメータがないときには invalid_request を返すことが追加

6. Refreshing an Access Token

BCP からリフレッシュトークンの発行・取り扱いに関する部分が転記されている

6.1. Refresh Token Protection

BCP からリプレイ攻撃検出のために sender-constrained reflesh token か reflesh token rotation を行うべきという部分が転記されている

7. Accessing Protected Resources

アクセストークンの検証仕様の例として Token Introspection や Access Token JWT が追加

7.1. Access Token Types

mac トークンタイプに関する記述が削除

7.2. Bearer Tokens

Bearer でのアクセストークン利用方法の記述。

基本的に RFC6750 から転記

ただし、2.3. URI Query Parameter の項目は転記されていない

7.2.1. Authenticated Requests

RFC6750 - Section 2. と同じ

7.2.1.1. Authorization Request Header Field

RFC6750 - Section 2.1. とほぼ同じ

HTTP 1.1 Authentication が RFC 化されているので、リンク先がそちらに変わっている

7.2.1.2. Form-Encoded Body Parameter

RFC6750 - Section 2.2. とほぼ同じ

7.2.2. The WWW-Authenticate Response Header Field

RFC6750 - Section 3. と同じ

7.2.3. Error Codes

RFC6750 - Section 3.1. と同じ

7.3. Error Response

「エラーレスポンスの詳細は仕様の範囲外」という表現から「トークンタイプによって決まる」という表現に変わり Bearer トークンでの例を挙げている

7.3.1. Extension Token Types

拡張したトークンタイプでのエラーに関する内容がこの項目にまとめられた。内容は同じ

7.4. Access Token Security Considerations

7.4.1. Security Threats

RFC 6750 - Section 5.1. から転記

7.4.1.1. Token manufacture/modification

RFC 6750 - Section 5.1. の同名項目と同じ内容

7.4.1.2. Token disclosure

RFC 6750 - Section 5.1. の同名項目と同じ内容

7.4.1.3. Token redirect

RFC 6750 - Section 5.1. の同名項目と同じ内容

7.4.1.4. Token replay

RFC 6750 - Section 5.1. の同名項目と同じ内容

7.4.2. Threat Mitigation

RFC 6750 - Section 5.1. の同名項目と同じ内容

7.4.2. Threat Mitigation

RFC6750 - Section 5.2. とほぼ同じ

7.4.3. Summary of Recommendations

7.4.3.1. Safeguard bearer tokens

RFC6750 - Section 5.3. の同名項目と同じ内容

7.4.3.2. Validate TLS certificate chains

RFC6750 - Section 5.3. の同名項目と同じ内容

7.4.3.3. Always use TLS (https)

RFC6750 - Section 5.3. の同名項目と同じ内容

7.4.3.4. Don't store bearer tokens in HTTP cookies

RFC6750 - Section 5.3. の同名項目と同じ内容

7.4.3.5. Issue short-lived bearer tokens

RFC6750 - Section 5.3. の同名項目と同じ内容

7.4.3.6. Issue scoped bearer tokens

RFC6750 - Section 5.3. の同名項目と同じ内容

7.4.3.7. Don't pass bearer tokens in page URLs

RFC6750 - Section 5.3. の同名項目と同じ内容

7.4.4. Token Replay Prevention

BCP - Section 2.2.1. と同じ

7.4.5. Access Token Privilege Restriction

BCP - Section 2.3. と同じ

Resource Indicator が RFC となったのでリンク先が変更されている

8. Extensibility

8.1. Defining Access Token Types

変更なし

8.2. Defining New Endpoint Parameters

変更なし

8.3. Defining New Authorization Grant Types

変更なし

8.4. Defining New Authorization Endpoint Response Types

変更なし

8.5. Defining Additional Error Codes

Implicit Grant の部分が削除

9. Security Considerations

RFC6819 - OAuth 2.0 Threat Model and Security Considerations の他に BCP へのリンクが追加

9.1. Client Authentication

  • 冒頭の部分は BCP - Section 2.5. と同じ
  • 後の部分は元の文を少し変更したものに、クライアントタイプが増えた部分が反映されている

9.1.1. Client Authentication of Native Apps

RFC8252 - Section 8.5. と同じ内容

9.2. Registration of Native App Clients

RFC8252 - Section 8.4. と同じ内容

9.3. Client Impersonation

変更なし

9.3.1. Impersonation of Native Apps

RFC8252 - Section 8.6. と同じ内容

9.4. Access Tokens

  • Implicit Grant に関する部分を削除
  • 後半部分は別の項として独立

9.4.1. Access Token Privilege Restriction

RFC6749 - Section 10.3. の後半部分と BCP - Section 2.3. の前半部分

9.4.2. Access Token Replay Prevention

BCP - Section 2.3. の後半部分と sender-constrained なトークンを利用することを推奨している。例として mTLS

9.5. Refresh Tokens

大体同じ。クライアント認証ができない場合は、sender-constrained なリフレッシュトークンを発行するか、リフレッシュトークンローテーションを行うべきと明確に記載された

9.6. Client Impersonating Resource Owner

BCP - Section 4.14. と BCP - Section 4.14.1. の内容をまとめた

9.7. Protecting Redirect-Based Flows

BCP - Section 2.1. とほぼ同じ内容

9.7.1. Loopback Redirect Considerations in Native Apps

RFC8252 - Section 8.3. と同じ

9.7.2. HTTP 307 Redirect

HTTP 307 は直前のメソッドが POST なら POST を行う。よってユーザーの認証情報を POST したときのレスポンスに 307 を使用すると認証情報をクライアントに POST してしまい、悪意のあるクライアントにクレデンシャルが開示されてしまう。よって常に GET でのリダイレクトを行い、POST リクエストボディ内のフォームデータをドロップする 303 を推奨する

BCP Section 4.11. とほぼ同じ

9.8. Authorization Codes

  • TLS の使用が SHOULD から MUST になった
  • 単一の認可コードの複数使用を検出したときにアクセストークンだけでなくリフレッシュトークンも無効化すべきとなった
  • PKCEの使用は MUST。ただし、confidential もしくは credentialed クライアントで nonce を使用しているときは RECOMMENDED
  • code_challenge と nonce はトランザクションに紐付いていなければならない。エラーになったら新しい値を使え
  • code_challenge_method は S256 を使うべき（現時点では。用は plain を使うな）
  • 認可リクエストに code_challenge があったら、トークンリクエストには code_verifier が無ければならない
  • 認可リクエストに code_challenge がなかったら、トークンリクエストに code_verifier があってはならない

PKCE に関しては基本的に BCP Section 2.1.1. と同じだが、AS の検証に対する言及などが追記されている

9.9. Request Confidentiality

  • 平文で送信してはいけないリソースから resource owner passwords が削除
  • 「認可コードを平文で送信すべきではない」が削除

9.10. Ensuring Endpoint Authenticity

変更なし

9.11. Credentials-Guessing Attacks

こっちでは resource owner passwords が削除されてない。多分削除漏れ

9.12. Phishing Attacks

変更なし

9.13. Fake External User-Agents in Native Apps

RFC8252 - Section 8.7. と同じ

9.14. Malicious External User-Agents in Native Apps

RFC8252 - Section 8.8. と同じ

9.15. Cross-Site Request Forgery

BCP Section 4.7. の内容に置き換えられた

9.16. Clickjacking

BCP Section 4.15. の内容に置き換えられた

9.17. Code Injection and Input Validation

変更なし

9.18. Open Redirectors

BCP Section 4.10. の内容に置き換えられた

9.19. Authorization Server Mix-Up Mitigation in Native Apps

RFC8252 - Section 8.10. と同じ内容だが通常の Mix-Up セクションとマージする予定らしい

9.20. Embedded User Agents in Native Apps

RFC8252 - Section 8.12. とほぼ同じ

9.21. Other Recommendations

Section 9.6. に書いてあることが再度書いてある

10. Native Applications

元の文と RFC8252 - Section 4. をマージしている

10.1. Using Inter-App URI Communication for OAuth in Native Apps

RFC8252 - Section 5. とほぼ同じ

10.2. Initiating the Authorization Request from a Native App

RFC8252 - Section 6. とほぼ同じ

PKCE は常に必須なので、あえてネイティブアプリだけに言及する必要は無いため削除されている

10.3. Receiving the Authorization Response in a Native App

RFC8252 - Section 7. と同じ

10.3.1. Private-Use URI Scheme Redirection

RFC 8252 - Section 7.1. とほぼ同じ

10.3.2. Claimed "https" Scheme URI Redirection

RFC 8252 - Section 7.2. と同じ

10.3.3. Loopback Interface Redirection

RFC 8252 - Section 7.3. と同じ

11. Browser-Based Apps

draft-ietf-oauth-browser-based-apps - OAuth 2.0 for Browser-Based Apps が Fix したら持ってくるらしい

12. Differences from OAuth 2.0

このドラフトは以下の文書を統合したもの

変更点

  • Authorization Code Grant を PKCE で拡張した
  • Implict Grant を廃止
  • Resource Owner Password Credentials Grant を廃止
  • URI のクエリストリングでの bearer トークンの削除
  • リフレッシュトークンは sender-constrained もしくはワンタイムトークンとすべき

けっこう足りなく無いか？？

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment