OAuth 2.1 の変更点

https://techinfoofmicrosofttech.osscons.jp:443/index.php?OAuth%202.1

[ トップ ]   [ 編集 | 差分 | バックアップ | 添付 | リロード ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• 追加された行はこの色です。
• 削除された行はこの色です。
• OAuth 2.1 へ行く。
• OAuth 2.1 の差分を削除

---

「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>OAuth]]
-戻る（[[OAuth]]、[[OAuth 2.0 拡張]]）
--[[OAuth 1.0]]
--[[OAuth 2.0]]
--[[OpenID Connect]]
--OAuth 2.1
--[[OAuth XYZ(3.0)>Transactional Authorization(XYZ)]]

* 目次 [#v7962435]
#contents

*概要 [#j8dc7bbc]
-[[OAuth 2.0]]のドキュメントの再整理という側面が強い提案。
-これだけ読めば現代のOAuthが理解できる。と言うドキュメントを目指した取り組み。

**AIによる要約 [#n4a8de9a]
-[[OAuth 2.0]]（RFC 6749）の後継となるセキュリティ強化版の認可フレームワーク。
-正式なRFC化に向けて策定が進められており、複数の拡張仕様を統合しながら脆弱なフローを廃止することが主な目的。
-利用可能なフローは「[[Authorization Code + PKCE>#c4c21546]]」「[[Client Credentials>#o73b8231]]」「[[Device Authorization>#h765a63b]]」の３つ。

***略語まとめ [#n95e8161]
-AT：Access Token
-RT：Refresh Token
-AS：Authorization Server
-RS：Resource Server
-PKCE：Proof Key for Code Exchange
-[[DPoP>OAuth2.0 DPoP]]：Demonstration of Proof of Possession
-[[mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]：mutual TLS

***強化 [#d968e8c4]
以下、10章の変更点（強化）を一覧化

-Authorization CodeのPKCE必須化：コードインジェクション対策

-リダイレクトURI完全一致：不正リダイレクト対策
--/authorize リクエスト受信時 — 登録済みURIと一致確認
--/token リクエスト受信時 — 再度一致確認

-RT制限：Sender Constraintまたはローテーションを導入して攻撃対策
--Confidentialクライアントは、Sender Constraintが推奨。
--Publicクライアントの、ローテーションが推奨。

※ Sender Constraintとは、持参人切符 → 記名式切符の話。~
※ 記名式切符には、クライアントの公開鍵サムプリント埋め込む。~
※ Sender Constraintには、[[DPoP>OAuth2.0 DPoP]]、[[mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]がある。

***廃止 [#n4ffe01c]
以下、10章の変更点（廃止）を一覧化

-ROPCグラント廃止：認証情報の直接受け渡し排除
-Implicitグラント廃止：トークン漏洩・インジェクション対策
-（Implicit）URIクエリへのトークン禁止：トークン露出対策

***修正 [#cd2ebfa1]
以下、10章の変更点（修正）を一覧化

-トークンリクエストからredirect_uri削除：PKCEで代替済み・仕様の簡略化

**クライアントの識別 [#z0f3ae50]
上記はOAuth2.1の必須の変更点だが、クライアント識別系のトピックは推奨（別仕様（BCP: RFC 9700等）に委ねる設計思想）。

-必須（MUST）  → PKCE、リダイレクトURI完全一致、RT制限
-推奨（SHOULD）→ private_key_jwt、[[mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]等の強固なClient認証
-許容（MAY）   → client_secretを用いたClient認証（後方互換のため残存）

***トークン要求時（クライアント認証） [#x336a0be]
private_key_jwt：Confidentialクライアントで、トークン・リクエスト時にASへのクライアント認証を行う。

***トークン利用時（クライアント識別） [#w2225d48]
-[[DPoP>OAuth2.0 DPoP]]：DPoPトークンリクエストで埋込み、トークン利用時にSender Constraint。
-[[mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]]：トークンリクエストでクライアント認証しつつ埋込み、トークン利用時にSender Constraint。

※ OAuth 2.1 ではSender Constraintは、RTの利用が対象だが、ATにも適用はできる。

*詳細 [#od320658]
フローについて書いていく。

**Authorization Code + PKCE [#c4c21546]

***認可リクエスト [#bc5f2ce5]
 GET /authorize
   ?response_type=code
   &client_id=<client_id>
   &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
   &scope=openid%20profile%20email
   &state=<state>
   &code_challenge=BASE64URL(SHA256(ASCII(code_verifier)))
   &code_challenge_method=S256
 Host: authserver.example.com

***認可レスポンス [#kd1cf19a]
認証画面をパスした後にリダイレクトされる。

 HTTP/1.1 302 Found
 Location: https://client.example.com/cb
   ?code=<auth_code>&state=<state>

※ 従来、Confidentialの場合「？」Publicの場合「＃」でパラメタを送信すると良いと言われてきた。コレは、response_mode=query（デフォルト）/fragment で指定できる。~
※ response_mode=fragment/form_postならサーバ・ログに出力されず、response_mode=query/form_postならクライアント・ログに出力されない。サーバ出力の方がマシなのでquery推奨らしい。

***トークン・リクエスト [#qc5ff54e]
リダイレクトされた先はクライアントで、ソコから。

 POST /token HTTP/1.1
 Host: authserver.example.com
 Content-Type: application/x-www-form-urlencoded
  grant_type=authorization_code
  &code=<auth_code>
  &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
  &client_id=<client_id>
  &code_verifier=<code_verifier>

※ Confidentialの場合「Authorization: Basic BASE64(<client_id>:<client_secret>)」を追加しボディのclient_idを削除

***トークン・レスポンス [#ufdf9ca9]

 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 
 {
   "access_token":  "eyJ...",
   "token_type":    "Bearer",
   "expires_in":    3600,
   "refresh_token": "eyJ...",
   "scope":         "openid profile email",
   "id_token":      "eyJ..."
 }

※ refresh_token は、Publicクライアントには原則不発行~
※ Publicクライアントにrefresh_tokenを発行するならローテーション化が必要。~
※ しれっと「id_token」がある。と言う事は、[[OIDC>OpenID Connect]]にも対応（scopeにopenidがある）。

**Client Credentials [#o73b8231]

***リクエスト [#lb06884c]

-クライアント認証: HTTP Basic 認証
 POST /token HTTP/1.1
 Host: auth.example.com
 Authorization: Basic <base64(id:secret)>
 Content-Type: application/x-www-form-urlencoded
 grant_type=client_credentials
 &scope=read:data write:data

-クライアント認証: リクエストボディ（非推奨）
 POST /token HTTP/1.1
 Host: auth.example.com
 Content-Type: application/x-www-form-urlencoded
 grant_type=client_credentials
 &client_id=s6BhdRkqt3
 &client_secret=gX1fBat3bV
 &scope=read:data write:data

-クライアント認証: private_key_jwt（推奨）
 POST /token HTTP/1.1
 Host: auth.example.com
 Content-Type: application/x-www-form-urlencoded
 grant_type=client_credentials
 &client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
 &client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJpc3MiOi...
 &scope=read:data write:data

***レスポンス [#j49a68d4]
 { "access_token": "eyJ...",
 "token_type": "Bearer",
 "expires_in": 3600,
 "scope": "read:data write:data" }

※ refresh_token は発行しない（トークン期限切れ後は再度このフロー全体を実行する）

**[[Device Authorization>OAuth 2.0 Device Authorization Grant]] [#h765a63b]

***認可リクエスト [#yabb0432]
 POST /device_authorization HTTP/1.1
 Host: auth.example.com
 Content-Type: application/x-www-form-urlencoded
 client_id=<id> &scope=openid profile

***認可レスポンス [#cd45a1d0]
 { "device_code": "GmRhmh...",
 "user_code": "WDJB-MJHT",
 "verification_uri": "https://auth/activate",
 "expires_in": 1800,
 "interval": 5 }

***画面への入力 [#j916f660]
 GET /activate?user_code=WDJB-MJHT

***トークン・リクエスト [#p44ca0eb]
（ポーリング）
 POST /token (grant_type=urn:ietf:params:oauth:grant-type:device_code)

***トークン・レスポンス [#o37c47a4]
（ポーリング）
-
 {"error":"authorization_pending"} または {"error":"slow_down"}

-
 { "access_token": "eyJ...","token_type": "Bearer", "refresh_token": "..." }

**移行について [#w4738b8c]

***IDP [#y7cb3881]
-Implicit と ROPC のサポートを削除
-リフレッシュ・トークンのSender Constraintやローテーション制限が必要

***SP/RP [#w6a2660f]
-認可リクエストをAuthorization Code + PKCEに変更。
-特に、response_mode=query/は、Confidential/Publicを問わずqueryにする。
-リフレッシュ・トークンは、
--Confidentialクライアントは、Sender Constraintが推奨。
--Publicクライアントの、ローテーションが推奨。

*参考 [#x9f07341]

**公式 [#cdf3f5bc]
-https://oauth.net/2.1/
-https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1

**内部リンク [#z925715f]
***[[OAuth 2.0]] [#sc06c615]
***[[OAuth PKCE]] [#t63f77f6]
***[[OAuth2.0 DPoP]] [#ec32083f]
***[[OAuth2.0 mTLS>OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens]] [#m06eb4b8]
***[[OAuth 2.0 Device Authorization Grant]] [#n3ba9572]

----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]

       

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.002 sec.