OAuth 2.1 のバックアップ(No.8)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• OAuth 2.1 へ行く。
  • 1 (2020-03-12 (木) 11:31:00)
  • 2 (2020-03-12 (木) 11:31:53)
  • 3 (2026-05-14 (木) 16:24:58)
  • 4 (2026-05-15 (金) 16:44:18)
  • 5 (2026-05-17 (日) 16:32:05)
  • 6 (2026-05-19 (火) 18:23:20)
  • 7 (2026-05-20 (水) 16:53:49)
  • 8 (2026-05-21 (木) 15:16:50)

---

「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る
  • OAuth 1.0
  • OAuth 2.0
  • OpenID Connect
  • OAuth 2.1
  • OAuth XYZ(3.0)

目次 †

概要 †

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

AIによる要約 †

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

略語まとめ †

• AT：Access Token
• RT：Refresh Token
• AS：Authorization Server
• RS：Resource Server
• PKCE：Proof Key for Code Exchange
• DPoP：Demonstration of Proof of Possession
• mTLS：mutual TLS

強化 †

以下、10章の変更点（強化）を一覧化

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

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

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

※ Sender Constraintとは、持参人切符 → 記名式切符の話。
※ 記名式切符には、クライアントの公開鍵サムプリント埋め込む。
※ Sender Constraintには、DPoP、mTLSがある。

廃止 †

以下、10章の変更点（廃止）を一覧化

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

修正 †

以下、10章の変更点（修正）を一覧化

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

クライアントの識別 †

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

• 必須（MUST） → PKCE、リダイレクトURI完全一致、RT制限
• 推奨（SHOULD）→ private_key_jwt、mTLS等の強固なClient認証
• 許容（MAY） → client_secretを用いたClient認証（後方互換のため残存）

トークン要求時（クライアント認証） †

private_key_jwt：Confidentialクライアントで、トークン・リクエスト時にASへのクライアント認証を行う。

トークン利用時（クライアント識別） †

• DPoP：DPoPトークンリクエストで埋込み、トークン利用時にSender Constraint。
• mTLS：トークンリクエストでクライアント認証しつつ埋込み、トークン利用時にSender Constraint。

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

詳細 †

フローについて書いていく。

Authorization Code + PKCE †

認可リクエスト †

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

認可レスポンス †

認証画面をパスした後にリダイレクトされる。

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推奨らしい。

トークン・リクエスト †

リダイレクトされた先はクライアントで、ソコから。

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を削除

トークン・レスポンス †

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にも対応（scopeにopenidがある）。

Client Credentials †

リクエスト †

• クライアント認証: 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

レスポンス †

{ "access_token": "eyJ...",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "read:data write:data" }

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

Device Authorization †

認可リクエスト †

POST /device_authorization HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
client_id=<id> &scope=openid profile

認可レスポンス †

{ "device_code": "GmRhmh...",
"user_code": "WDJB-MJHT",
"verification_uri": "https://auth/activate",
"expires_in": 1800,
"interval": 5 }

画面への入力 †

GET /activate?user_code=WDJB-MJHT

トークン・リクエスト †

（ポーリング）

POST /token (grant_type=urn:ietf:params:oauth:grant-type:device_code)

トークン・レスポンス †

（ポーリング）

• {"error":"authorization_pending"} または {"error":"slow_down"}

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

移行について †

IDP †

• Implicit と ROPC のサポートを削除
• リフレッシュ・トークンのSender Constraintやローテーション制限が必要

SP/RP †

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

参考 †

公式 †

• https://oauth.net/2.1/
• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1

内部リンク †

OAuth 2.0 †

OAuth PKCE †

OAuth2.0 DPoP †

OAuth2.0 mTLS †

OAuth 2.0 Device Authorization Grant †

---

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.029 sec.