• 戻る（OAuth）
  • OAuth 2.1
  • OAuth 2.0
  • OAuth PKCE
  • OAuth 2.0 拡張

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

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

補足（位置づけ）: OAuth 2.1 は
新機能を足す仕様ではない点が重要である。
やっていることは次の 2 つに尽きる。

1. 既に BCP で「こうしろ」と言われていたことを必須にする
2. 危険なフローを仕様から削る

つまり「正しく実装していた人にとっては、ほぼ変更が無い」。
逆に言えば、OAuth 2.1 に適合しないなら、それは 2.0 の時点でも
安全ではなかったということになる。

なお 2026 年時点でも **Internet-Draft（未 RFC）**であるが、
内容は RFC 9700（Security BCP）とほぼ一致しており、
実務上は既に「これが標準」として扱ってよい。

略語	内容
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

項目	内容
Authorization Code の PKCE 必須化	コードインジェクション対策
リダイレクト URI 完全一致	不正リダイレクト対策。/authorize 受信時と /token 受信時の両方で一致確認
RT 制限	Sender Constraint またはローテーションを導入して攻撃対策

• RT 制限の使い分け
  • Confidential クライアント — Sender Constraint が推奨。
  • Public クライアント — ローテーションが推奨。

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

補足（Refresh Token ローテーション）: Public クライアントは
シークレットを持てないため、RT が盗まれると使われ放題になる。
そこで「RT を使うたびに新しい RT を発行し、古い方を無効化する」。

攻撃者と正規クライアントのどちらかが古い RT を使った時点で
再利用が検知でき、AS はそのトークン ファミリ全体を失効させられる。
盗難を防げはしないが、検知して被害を止められるのが利点である。

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

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

上記は OAuth 2.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 にも適用はできる。

• 認可リクエスト — response_type=code に加えて
  code_challenge / code_challenge_method=S256 を必須で付与する。
• 認可レスポンス — code と state を返す。
• トークン・リクエスト — code と code_verifier を POST する
  （redirect_uri は不要になった）。
• トークン・レスポンス — access_token / refresh_token / token_type 等を返す。

詳細は OAuth PKCE を参照。

ユーザー不在（マシン間）の通信で使用する。
grant_type=client_credentials を Token エンドポイントに POST する。

OAuth 2.0 Device Authorization Grant

1. 認可リクエスト — デバイスが AS に要求し、
   device_code / user_code / verification_uri を受け取る。
2. 画面への入力 — ユーザーが別端末で verification_uri を開き、user_code を入力。
3. トークン・リクエスト — デバイスは device_code で
   ポーリングし、承認され次第トークンを受け取る。

• IdP 側 — 廃止されたフロー（Implicit / ROPC）の提供を停止し、
  PKCE を必須化、redirect_uri を完全一致に変更する。
• SP/RP 側 — Implicit / ROPC を使っている実装を
  Authorization Code + PKCE に置き換える。

補足（移行の順序）: IdP と RP を同時に切り替えられないことが多い。
実務では次の順で進める。

1. PKCE を「受け付ける」ようにする（必須にはしない）
2. RP を順次 PKCE 対応にする（対応状況を計測する）
3. redirect_uri の完全一致を強制する
4. PKCE を必須にする
5. Implicit / ROPC を廃止する

5 を最初にやると全 RP が一斉に壊れるため、
「受け入れを広げてから、締める」順序が要点である。

• 公式（OAuth 2.1 Internet-Draft）
  https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
• RFC 9700 - Best Current Practice for OAuth 2.0 Security
  https://datatracker.ietf.org/doc/html/rfc9700

• OAuth 2.0
• OAuth PKCE
• OAuth 2.0 のトークン
• OAuth2.0 DPoP
• OAuth2.0 mTLS
• OAuth 2.0 Device Authorization Grant

---

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth