OAuth 2.0 の認可フロー内部（Authorization Code + PKCE）

OAuth 2.0 は「トークンの渡し方」の規格

OAuth 2.0（RFC 6749）は、ユーザーのパスワードを第三者アプリに渡さずに、限定された権限（スコープ）を表すアクセストークンを安全に発行・委譲するための枠組みです。登場人物は4者あります。

• リソースオーナー：本人（ユーザー）。
• クライアント：トークンを使いたいアプリ（SPA・モバイル・サーバー）。
• 認可サーバー：本人を認証し、コードやトークンを発行する。
• リソースサーバー：トークンを検証して API を提供する。

OAuth 2.0 が**認可（Authorization）の規格である点に注意が必要です。「この人が誰か」を確実に伝える認証（Authentication）**は OAuth 2.0 単体の責務ではなく、その上に OpenID Connect（OIDC） を載せて ID トークンを得ます。両者の役割分担は 認証と認可の違い の通りで、OAuth でログインを実装するときは OIDC を併用するのが正道です。

「フロー（グラントタイプ）」とは、この4者の間でどの経路を通ってトークンを受け渡すかの手順の違いにすぎません。経路が違えば、傍受や CSRF に対する強度も変わります。

4つのフローの違い

代表的な4フローを、用途と安全性の観点で並べます。

• Authorization Code：認可サーバーはまず短命の認可コードを返し、クライアントは**サーバー間の直接通信（バックチャネル）**でそのコードをトークンに交換します。トークンがブラウザの URL やフロントチャネルに露出しないのが安全性の核です。
• Implicit：コード交換を省き、#access_token=... の形でトークンをフラグメントに直接返していました。ブラウザ履歴・Referer・拡張機能に漏れやすく、リフレッシュトークンも安全に扱えないため、現在は PKCE 付き Authorization Code への一本化が勧告されています。
• Client Credentials：ユーザーが介在しないバッチやマイクロサービス間で、クライアント自身の client_id / client_secret を提示してトークンを得ます。人間の同意画面が無い点が他と決定的に違います。
• Device Authorization：キーボードの無いテレビや CLI 向け。本体は device_code を取得して画面に短いユーザーコードを表示し、ユーザーはスマホ等の別端末で承認、本体はトークン発行をポーリングで待ちます。

PKCE が code interception を防ぐ原理

Authorization Code の弱点は、認可コードがリダイレクトでブラウザを経由することです。とくにモバイルや SPA では client_secret を秘匿できないため、悪意あるアプリが OS のカスタム URL スキームを横取りするなどして認可コードを傍受すると、それをトークンに交換できてしまいます。これが code interception（認可コード傍受）攻撃です。

PKCE（Proof Key for Code Exchange、RFC 7636） は、コードを横取りされても交換できなくする仕組みです。要は「コードを開始した本人だけが知る秘密」を後出しで証明させます。

1. クライアントが乱数を生成:    code_verifier  （43〜128文字の高エントロピー文字列）
2. その SHA-256 を Base64URL:   code_challenge = BASE64URL(SHA256(code_verifier))
3. 認可リクエストに同梱:        code_challenge と code_challenge_method=S256 を送る
   → 認可サーバーは challenge を認可コードに紐付けて記憶
4. コールバックで認可コード受領
5. トークン交換時に提示:        元の code_verifier を送る
   → サーバーは SHA256(verifier) == 記憶した challenge を検証。一致しなければ拒否

攻撃者が認可コードを傍受しても、code_verifier は最初のリクエストを送った正規クライアントのメモリ内にしか存在しません。通信路に流れるのはハッシュ済みの code_challenge だけで、SHA-256 は一方向関数なので challenge から verifier を復元できません。よって傍受したコードを交換しようとしても verifier を提示できず、サーバーが弾きます。

PKCE は当初モバイル向けでしたが、現在は public client（secret を持てない SPA・モバイル）だけでなく confidential client でも全フローに付けるべきとされ、OAuth 2.1 のドラフトでは Authorization Code に PKCE が常時必須化されています。

state による CSRF 対策

PKCE は「コードの横取り」を防ぎますが、**「攻撃者が用意したコードを被害者に握らせる」**別系統の攻撃には別の対策が要ります。

攻撃者が自分のアカウントで認可を開始し、得たコールバック URL を罠ページから被害者のブラウザに踏ませると、被害者のクライアントセッションに攻撃者のアカウントが結び付く（ログイン CSRF／アカウント混同）危険があります。これを防ぐのが state パラメータです。

1. 認可リクエスト直前にクライアントが乱数 state を生成し、セッションに保存
2. 認可リクエストに state=<乱数> を付けて送る
3. 認可サーバーはコールバックで同じ state をそのまま返す
4. クライアントは「返ってきた state == セッションに保存した state」を検証
   → 一致しなければ、自分が始めたフローではないとみなし破棄

state は認可開始とコールバックが同一ブラウザ・同一セッション由来であることを保証する CSRF トークンそのものです。仕組みは CSRF（クロスサイトリクエストフォージェリ） のトークン照合と同型で、推測不能な乱数を「往復させて突き合わせる」点が共通します。state には戻り先 URL を持たせることもありますが、その場合も改ざん検知できる形で署名/照合する必要があります。

nonce によるリプレイ対策（OIDC）

state が OAuth のフロー全体を守るのに対し、nonce は OIDC の ID トークンを守る値です。役割を取り違えないよう、両者を整理します。

OIDC では認可リクエストに nonce=<乱数> を載せます。認可サーバーは発行する ID トークンの nonce クレームに同じ値を埋め込んで署名します。クライアントは ID トークン検証時に「自分が送った nonce と一致するか」を確認します。これにより、過去に発行された ID トークンを攻撃者が再注入してもセッションを取れません——古いトークンの nonce は現在のリクエストと一致しないからです。

認可リクエスト:  ...&nonce=Xk29...&...
ID トークン(JWT) のペイロード例:
  {
    "iss": "https://issuer.example",
    "aud": "client-123",
    "nonce": "Xk29...",   ← 送った nonce と一致するか検証
    "exp": 1750000000,    ← 期限切れも必ず確認
    "iat": 1749996400
  }

ID トークンの検証では nonce に加えて iss（発行者）・aud（自分宛か）・exp（期限）・署名をすべて確認します。ここを緩めると、別クライアント宛のトークンの流用や期限切れトークンの受理を許します。フィッシング耐性まで踏み込むなら、認証要素そのものを公開鍵チャレンジにする FIDO2 / WebAuthn や、second factor の TOTP/HOTP と組み合わせる設計が有効です。

どのフローを選ぶか

判断は「ユーザーが介在するか」「secret を秘匿できるか」「端末が入力可能か」の3点でほぼ決まります。

結論として、ユーザーが関わるフローは例外なく Authorization Code + PKCEを選び、state を必ず照合し、ログインを伴うなら OIDC の nonce を加える——これが現行の正解です。Implicit は新規採用せず、既存実装も移行対象です。PKCE がコード傍受を、state が CSRF を、nonce がリプレイを、それぞれ別々の角度から塞いでいる点を理解しておけば、ライブラリ設定の意味も、監査で何を見るべきかも明確になります。