OAuth 2.0/OIDCの深淵：PKCE強制とトークン管理の「現場的」リアリティ
セキュリティアーキテクト諸君。教科書的な「OAuth 2.0を使いましょう」という勧告は、もはやエンジニアへの挨拶にもならない。今、我々が対峙しているのは、仕様の隙間を縫ってメモリ上のトークンを奪取し、TLS終端の脆弱性を突き、さらにはLLMのコンテキストウィンドウを汚染して認可スコープを拡張しようとする「プロ」たちの動きだ。
本稿では、APIセキュリティの最前線で、いかにしてOAuth 2.0とOpenID Connect (OIDC) を「防弾」にするか、その技術的核心を掘り下げる。
—
1. 認可コードフロー + PKCE：ただの「必須」ではない理由
多くのジュニアエンジニアは「PKCE（Proof Key for Code Exchange）はモバイルアプリのためのもの」と誤解している。これは大きな間違いだ。現代のWebアーキテクチャにおいて、PKCEは全てのクライアント（SPAを含む）で必須である。
なぜか？ 認可コード（Authorization Code）が、リダイレクトURLの漏洩や、ブラウザの履歴、あるいは悪意あるブラウザ拡張によって盗まれるリスクを完全に排除するためだ。
防御のロジック：コードインターセプション攻撃への対抗
攻撃者は認可コードを奪った後、自身のクライアントIDを使ってトークンエンドポイントへ叩き込もうとする。しかし、PKCEを実装していれば、攻撃者は`code_verifier`を知り得ないため、トークン交換は拒絶される。
実装上の注意点（推奨パラメーター設定）:
// クライアント側: code_verifierの生成は暗号学的に安全な乱数を使用する
const verifier = generateRandomString(128); // 43-128文字の範囲で最大長を推奨
const challenge = base64URLEncode(sha256(verifier)); // SHA256ハッシュが必須
// 認可リクエスト送信時
// code_challenge_method=S256 を必ず指定すること。
// ‘plain’は中間者攻撃(MITM)に対して脆弱であり、監査で即座に指摘対象となる。
—
2. トークンライフサイクルの「動的な」防衛戦略
アクセストークンの短寿命化は常識だが、その「短さ」をどう定義し、リフレッシュトークンをどう管理するかで、システムの耐性が決まる。
リフレッシュトークン回転（Rotation）の極意
リフレッシュトークンを使い回すのは、パスワードを使い回すのと同じだ。我々が推奨するのは「Refresh Token Rotation」である。
- 動作の仕組み: リフレッシュトークンが使用されるたびに、古いトークンは無効化され、新しいペアが発行される。
- インシデントハンドリングの盲点: もし攻撃者が古いリフレッシュトークンを再利用した場合、AS（認可サーバー）は「トークンが漏洩した」と判断し、該当するユーザーの全セッションを即座に無効化（Revocation）しなければならない。
実装サンプル：Redisによるセッション管理
// 擬似コード: リフレッシュトークンの検証と回転
func rotateRefreshToken(oldToken string) (newToken string, err error) {
if !isValid(oldToken) {
// 既に使われたトークンの再利用は、漏洩のシグナルとみなす
revokeAllTokensForUser(userID)
return “”, ErrCompromisedSession
}
// 新しいトークンを発行し、古いものを墓場へ送る
return issueNewTokenPair(userID)
}
—
3. 生成AI時代の新たな脅威：プロンプトインジェクションと認可
最近、LLMを用いたアプリケーションが爆発的に増えているが、ここでOIDCの`id_token`を安易にLLMへ渡すのは極めて危険だ。
「権限昇格」を許さないガードレイル設計
LLMが外部ツール（API）を呼び出す際、そのAPIがOIDCの認可に依存している場合、LLMへの入力（プロンプト）がAPIのスコープを操作する可能性がある。
- ガードレイル: APIゲートウェイで、トークンのスコープを細分化（Least Privilege）せよ。LLM用トークンには、`read:only`権限しか持たせないのが鉄則だ。
- アーキテクチャ: 認可サーバーとLLMの中間に「Context Sanitizer」を配置し、トークンが持つクレーム（`aud`, `sub`）と、LLMがリクエストしようとしているAPIの要求スコープが整合しているか、バイナリレベルで検証するレイヤーを構築せよ。
—
4. 最後に：監査と継続的な監視の視点
セキュリティアーキテクトとして、最後に一つ忠告がある。「実装して終わり」は、脆弱性の始まりだ。
- パケットレベルの監視: TLS 1.3以降、通信の可視性は低下したが、それでも認可フローの異常なトラフィックパターン（短時間に大量のトークンリクエスト、異常なリダイレクト先）は、WAFやIDSで検出可能だ。
- 耐量子暗号への移行: RSAベースの署名アルゴリズムから、ECDSA（P-256）への完全移行はもちろん、近い将来の量子耐性署名（Dilithium等）のロードマップを現在のアーキテクチャに描いておくこと。
我々の仕事は、侵入を100%防ぐことではない。攻撃者のコストを跳ね上げ、彼らが「このシステムは割に合わない」と判断してターゲットを変えるまで、泥臭く防御を積み上げることだ。
コードを書け。ただし、そのコードが攻撃者の踏み台にならないよう、常に最悪のシナリオを想像しながら。
コメント