OAuth 2.1草案におけるPKCEとセキュリティ要件の読み方
OAuth 2.1はまだIETF草案です。公開済みのRFC 9700と、PKCE・リダイレクトURI・リフレッシュトークンに関する草案の記述を区別し、導入時の確認項目に整理します。
発行・訂正窓口:infostoa · 編集基準
この記事の個別の執筆者・専門査読者の情報は提供されていません。
まず文書の状態を確認する
2026年10月12日に確認したIETF Datatrackerでは、draft-ietf-oauth-v2-1-16はActive Internet-Draftで、RFCとしての状態は割り当てられていません。Internet-Draftは作業中の文書なので、OAuth 2.1を確定済み仕様として引用しないでください。すでに公開されている基準はOAuthセキュリティのベストプラクティスRFC 9700で確認し、OAuth 2.1はその内容をまとめる途中で変更され得る草案として読みます。
PKCEが結び付けるもの、保護しないもの
PKCEは、一度だけ使うcode_verifierによって認可リクエストと後続のトークン交換を結び付けます。クライアントはリクエストごとに推測困難な検証子を生成し、そこから導出したcode_challengeを認可エンドポイントへ送ります。認可コードをトークンと交換するとき、トークンエンドポイントで検証子を提示します。認可コードだけを盗んだ攻撃者が自分の検証子で交換するリスクを下げる仕組みです。発行後のアクセストークンを守ったり、ブラウザーのXSSを防いだりするものではありません。
現在のRFC 9700は、パブリッククライアントにPKCEの使用をMUST、機密クライアントにはRECOMMENDEDとしています。OAuth 2.1草案の認可コードフローも標準の使い方ではPKCEパラメーターを含みますが、§7.5.1の特定条件を満たす場合はcode_challengeの例外があります。草案は検証子を露出しない方式を要求し、現時点で該当する方式はS256のみと記しています。これはすべてのOAuthグラントにPKCEを要求することでも、クライアント認証用シークレットを置き換えることでもありません。PKCEとクライアント認証は別の役割です。
公開基準と草案を分けた導入確認
| 項目 | 公開済みの基準 | OAuth 2.1草案の方向 | 導入環境で確認すること |
|---|---|---|---|
| PKCE | RFC 9700:パブリッククライアントはMUST、機密クライアントはRECOMMENDED | 認可コードフローの標準形に含む。§7.5.1の例外とS256の記述を確認 | SPA・ネイティブアプリでリクエストごとに新しい検証子を生成し、S256を使うか。サーバーアプリのクライアント認証を別に維持しているか |
| リダイレクトURI | RFC 9700 §2.1:登録URIとの完全な文字列一致がMUST。ネイティブアプリのlocalhostポートは例外 | RFC 9700のルールを参照 | プロバイダーの比較動作と、限定的なネイティブのloopback例外を確認 |
| パブリッククライアントのリフレッシュトークン | RFC 9700 §2.2.2:送信者制約またはローテーションがMUST | 草案は公開クライアントのトークンを送信者制約または一回限りの使用と整理 | 再利用の検出、トークン失効、復旧手順をプロバイダー資料で確認 |
| 古いグラント | RFC 9700はインプリシットグラントの使用を、明記された緩和策の例外を除きSHOULD NOTとし、パスワード資格情報グラントはMUST NOTとしています | どちらも草案から除外 | 設定やログで利用状況を確認し、認可コードフローへの移行を計画 |
localhostの例外は、任意のワイルドカードを許すものではありません。RFC 9700がポート番号の例外を認めるのは、ネイティブアプリのlocalhostリダイレクトです。それ以外の登録・比較範囲は、プロバイダーの設定とRFC本文で確認してください。
仮想の導入レビュー例
SPAとサーバーレンダリングアプリを運用するチームを想定します。まずIDプロバイダーの設定から、各アプリのグラントとクライアント種別を記録します。SPAでは、認可リクエストに送るのがS256から導出したcode_challengeとcode_challenge_method=S256だけで、元のcode_verifierを含めていないか確認します。検証子はクライアント内に保持し、認可コードを交換するときにトークンエンドポイントだけへ送ります。サーバーアプリでは、クライアント認証をPKCEとは別に維持しているかを見ます。登録済みリダイレクトURIと実際のリクエストを照合し、ネイティブloopbackのポート例外を通常のWeb URIに広げないようにします。最後に、パブリッククライアントのリフレッシュトークン再利用時に失効または送信者証明の確認が行われるか、プロバイダーの資料とログで確認します。これは説明用の仮想的な確認手順で、特定製品で実行したテスト結果ではありません。
採用を判断する
「OAuth 2.1」という製品設定のチェックボックスだけで判断しないでください。公開済みのRFC 9700を基準に、クライアント種別ごとの現行設定を確認し、草案の条項は版と例外を記録して追跡します。PKCEは認可コード窃取への緩和策であり、トークン保管の設計やXSS対策を代替しません。ブラウザーのトークン管理は別の脅威モデルで決めてください。