PKCE Downgrade Attacks: なぜOAuth 2.1はもはやオプションではない 🔑📉

サイバーセキュリティの急速に進化する環境では、かつて「十分に安全」と考えられていたプロトコルも、現代の攻撃手法によって破られつつあります。10年以上にわたり、OAuth 2.0 (RFC 6749) はウェブやモバイル認証の基盤でした。しかし、2026年1月以降、業界は重要な転換点に達しています。OAuth 2.1の安定化とRFC 9700（セキュリティのベストプラクティス）の公開により、PKCE（Proof Key for Code Exchange）なしの「標準的な」Authorization Codeフローはもはや「非推奨」ではなく、「リスク」となっています。

この記事では、PKCEダウングレード攻撃の技術的仕組み、公開クライアントで静的な client_secret を使用することが「セキュリティの演技」に過ぎない理由、そしてユーザーを巧妙なトークン盗難から守るためにOAuth 2.1への移行が唯一の方法である理由について解説します。

1. OAuth 2.0の終焉：OAuth 2.1とは何か？

OAuth 2.1は新しいプロトコルではありません。むしろ、2012年以降にリリースされたさまざまなセキュリティ拡張と「ベスト現在のプラクティス」（BCPs）の統合です。OAuth 2.0を「整理」し、安全性の低い機能を排除し、一度任意だったセキュリティ対策を義務化しています。

OAuth 2.1の主な変更点：

PKCEは必須: バックエンドサーバ（機密クライアント）やモバイルアプリ/SPA（公開クライアント）を問わず、すべてのAuthorization CodeフローでPKCEを使用しなければなりません。

Implicit Grantの廃止: URLフラグメントにトークンを直接返す「Implicit」フローは正式に廃止されました。

ROPCの廃止: 「リソース所有者パスワードクレデンシャル」グラント（アプリがユーザのパスワードを扱う）はなくなりました。

正確なリダイレクトURIの一致: ワイルドカードを含むリダイレクトURIは許可されず、サーバはビット単位で一致させる必要があります。

OAuth 2.1への移行は、「フロントチャネルでのコードの盗聴に脆弱」という認識から推進されています。

2. 盗聴攻撃の仕組み

PKCEが必要な理由を理解するには、攻撃者がモバイルやシングルページアプリケーション（SPA）で認証コードをどのように盗むかを見る必要があります。

モバイルアプリ & カスタムURLスキーム

モバイル環境では、アプリはしばしばカスタムURLスキーム（例：my-app://callback）を介して通信します。ユーザがモバイルブラウザで認証を終えると、認証サーバ（AS）はこのスキームを使ってアプリにリダイレクトします。

脆弱性: 多くのOSでは、複数のアプリが同じカスタムURLスキームを登録できます。悪意のあるアプリがmy-app://を登録している場合、正規のアプリの代わりにリダイレクトを受け取り、認証コードを取得できてしまいます。

SPAとブラウザ履歴

シングルページアプリ（SPA）では、認証コードはブラウザのURLパラメータとして渡されます。このコードは以下の方法で漏洩します：

• ブラウザ履歴: 攻撃者がデバイスにアクセスできれば、履歴を確認できます。
• Refererヘッダー: リダイレクト後に第三者のスクリプト（広告トラッカーなど）にリクエストを送ると、コードを含むURLがRefererヘッダーに送信されることがあります。
• ログ: プロキシサーバやブラウザ拡張機能がURL全体を記録している場合もあります。

3. PKCEとは何か？（現代の盾）

PKCE（Proof Key for Code Exchange）は、RFC 7636で定義されており、もともとはモバイルアプリのカスタムURLスキーム問題を解決するために設計されました。フローに以下の3つの新要素を導入します：

• Code Verifier: クライアントが各リクエストごとに生成する暗号学的にランダムな文字列。
• Code Challenge: verifierのハッシュ（通常はSHA-256）を用いたもの。
• Code Challenge Method: 使用するアルゴリズム（例：S256）。

PKCEの仕組み：

1. 開始: クライアントはcode_verifierを生成し、それをハッシュしてcode_challengeを作成し、これを認証サーバに送信します。

2. コードの発行: ASは認証コードを発行しますが、code_challengeに「紐付け」ます。

3. 交換: クライアントがコードとトークンを交換する際、未ハッシュのcode_verifierを送信します。ASは verifierをハッシュし、最初に送信されたcode_challengeと一致するか確認します。

盗難防止の理由: 攻撃者が認証コードを盗んでも、code_verifier（クライアントから一度も離れていない）を持っていないため、コードは無意味です。

4. PKCEダウングレード攻撃：隠された罠

PKCEダウングレード攻撃は、認証サーバがPKCEをサポートしているが、すべてのクライアントに対して強制していない場合に発生します。

攻撃シナリオ：

1. 設定: 攻撃者が中間に入り（例：乗っ取られたブラウザ拡張や悪意のあるアプリを通じて）

2. 改ざん: 正規のクライアントがOAuthフローを開始するとき、code_challengeを含むリクエストを送信します。

3. ダウングレード: 攻撃者は最初のリクエストを傍受し、code_challengeとcode_challenge_methodパラメータを削除します。

4. サーバのエラー: ASが「後方互換性」を持たせて設定されている場合、PKCEパラメータのないリクエストを見て、「古い」クライアントとみなします。標準の非PKCEフローを進めます。

5. コードの盗難: ASはコードを発行します。攻撃者はカスタムURLスキームやブラウザ履歴を通じてこれを傍受します。

6. リターン: ASはPKCEなしのフローとみなすため、code_verifierの要求をしません。攻撃者は盗んだコードを使って有効なアクセストークンと交換します。

OAuth 2.1の修正点: PKCEを必須にすることで、認証サーバはcode_challengeがないリクエストを拒否し、「ダウングレード」経路を完全に排除します。

5. なぜclient_secretは「セキュリティの演技」なのか

多くの開発者は、client_secretを使うことで安全だと信じています。これはConfidential Clients（サーバ側で秘密を隠す）には当てはまりますが、Public Clients（モバイルやSPA）には全く当てはまりません。

SPAの誤解

JavaScriptベースのSPAにclient_secretを置くと、それは公開情報です。ChromeのF12を押して「ソース」タブを開けば誰でも見つけられます。

モバイルの誤解

モバイルアプリはコンパイルされているため簡単に逆コンパイルされます。apktoolやGhidraのようなツールを使えば、攻撃者は静的文字列（秘密など）を数秒で抽出できます。

静的秘密の問題点:

client_secretは「身分証明」の証明ではなく、特定の取引の「所有証明」ではありません。一度漏洩すると、攻撃者は永遠にそのクライアントになりすますことができます。PKCEは、動的で一度きりの秘密（コード verifier）を使用し、各取引ごとに異なるセキュリティを提供します。これがOAuth 2.1がフロントチャネルのセキュリティにおいて静的秘密よりPKCEを推奨する理由です。

6. 現代のトークン盗難：コードを超えて

レガシーフローに頼ると、従来の防御を回避する現代のトークン盗難技術にさらされます：

認証コードインジェクション: 攻撃者は盗んだコードを自分のセッションに注入できます。PKCE（issパラメータやnonceとともに使用）を使えば、コードが特定のブラウザセッションに属していることを保証し、これを防ぎます。

情報窃盗ツール: マルウェアはブラウザのメモリからトークンを抽出できます。OAuth 2.1は、送信者に制約されたトークン（DPoP - Demonstrating Proof-of-Possession）を推奨しており、トークンはリクエストした特定のデバイスだけで使用可能です。

リフレッシュトークンの乱用: 過去にはSPA向けのリフレッシュトークンは危険とされていました。OAuth 2.1はこれを許容しますが、リフレッシュトークンのローテーションを義務付けています。使用ごとに新しいトークンが発行され、古いものは無効化されます。漏洩したリフレッシュトークンを攻撃者が使った場合、ASは「リプレイ」を検知し、セッション全体を終了させます。

7. SEO戦略：今日からOAuth 2.1を実装

セキュリティの向上と「安全なOAuth実装」の検索ランキングを狙う開発者・セキュリティアーキテクト向けに、2026年のチェックリストを紹介します：

ライブラリのアップグレード: SDK（例：AppAuth、MSAL、OIDC-client-ts）がPKCEにデフォルト対応していることを確認。

S256を強制: 「プレーン」PKCEは絶対に使わず、常にS256（SHA-256）を使用。

認証サーバの監査: Auth0、Okta、Keycloakなどの認証サーバを設定し、すべてのクライアントにPKCEを必須化。レガシーや互換モードを無効に。

フロントエンドからシークレットを除去: SPAやモバイルコードにclient_secretを含めるのはやめましょう。セキュリティの虚偽の安心感を与えるだけです。

正確な一致: リダイレクトURIを監査し、ワイルドカード（例：https://*.myapp.com）を使ったものは削除。

結論：新しい標準

OAuth 2.1の完成は、「十分に安全」だった時代の終わりを告げます。PKCEダウングレード攻撃は、2012年時代のOAuth 2.0実装に固執しているすべてのアプリにとって現実的な脅威です。

PKCEを義務化し、Implicit Grantを廃止し、厳格なリダイレクト一致を実施することで、OAuth 2.1は傍受や注入攻撃に対して堅牢な防御を提供します。セキュリティを「オプションの拡張」として扱うのはやめて、アプリケーションの基盤として捉える時です。