MCP認可のmix-up攻撃とトークン対策 — セキュリティ考慮事項を読む

MCP認可仕様の「Security Considerations」章は、OAuth 2.1のセキュリティベストプラクティスを土台にしています。そのうえで、MCP固有の脅威をMUST/SHOULD要件に分解しました。対象はトークン窃取・認可コード保護・mix-up攻撃・Confused Deputy問題です。

MCP認可のSecurity Considerations章が土台にするもの

MCP認可のセキュリティ要件は、独自に一から定義されたものではありません。仕様は冒頭で、OAuth 2.1のSection 7「Security Considerations」に従うことをMUST要件にしています。MCP固有の追加要件はその上に積む構成です。

章立ては9項目です。

• Token Audience Binding and Validation
• Token Theft
• Communication Security
• Authorization Code Protection
• Mix-Up Attacks
• Open Redirection
• Client ID Metadata Document Security
• Confused Deputy Problem
• Access Token Privilege Restriction

複数の認可サーバーとやり取りする、サードパーティAPIの仲介役になるといったMCP特有の状況で目立つ脅威が、OAuth 2.1の一般論の上に載っています。

認可フローの7段階とClaude Codeの実装の積み重ねはリモートMCPのOAuth認証に、サーバー接続前の信頼判断はMCPセキュリティガイドにあります。ここでは、その各段階で何が狙われるかを仕様原文の側から追います。

トークンの宛先をどう縛るか

RFC 8707のResource Indicatorsは、認可サーバーが対応している場合にトークンを本来の宛先へ確実に紐づける仕組みです。仕様はMCPクライアントに対し、認可リクエストとトークンリクエストの両方でresourceパラメーターを含めることをMUST要件にしています。MCPサーバー側にも、提示されたトークンが自分宛てに発行されたものかどうかの検証がMUST要件です。

トークン窃取そのものへの対策は別の項目で扱われます。クライアントに保存されたトークンや、サーバー側でキャッシュ・ログに残ったトークンを攻撃者が入手すると、正規のリクエストに見える形で保護リソースへアクセスできてしまいます。仕様はOAuth 2.1のSection 7.1に沿った安全なトークン保存をMUST要件としました。認可サーバーには短命なアクセストークンの発行をSHOULD要件として求めます。クライアントシークレットを安全に保持できないパブリッククライアントでは、リフレッシュトークンのローテーションがMUST要件です。

認可コードを守るPKCEとS256

認可レスポンスに含まれる認可コードを攻撃者が横取りすると、そのままアクセストークンと交換されてしまいます。対策としてMCPクライアントはPKCE(Proof Key for Code Exchange、認可コード横取り対策)の実装がMUST要件です。コードチャレンジの生成方式にはS256を技術的に可能な限り使うことがMUST要件で、plain方式ではなくS256を使うことが求められます。

PKCEのサポートを認可サーバーがどう広告しているかも、仕様は具体的に定めます。OAuth 2.1とPKCEの仕様には、クライアントが対応状況を調べる仕組みがありません。そこで認可サーバーメタデータを頼りにします。

• OAuth 2.0 Authorization Server Metadataでcode_challenge_methods_supportedが無ければ、PKCE非対応とみなす。認可処理は進めない(MUST)
• OpenID Connect Discoveryでは、このフィールドが標準のメタデータに定義されていないものの、多くのプロバイダーが含めています。クライアントは存在を確認し、無ければ処理を拒否する(MUST)
• OpenID Connect Discoveryを提供する認可サーバーは、MCPとの互換性のためにこのフィールドを含める(MUST)

通信経路そのものの保護もOAuth 2.1準拠のMUST要件です。認可サーバーの全エンドポイントはHTTPS経由での提供が必須で、リダイレクトURIはlocalhostであるかHTTPSを使うかのいずれかでなければなりません。

Mix-Up攻撃はなぜPKCEだけでは防げないのか

MCPクライアントは稼働期間中に複数の認可サーバーとやり取りします。攻撃者がそのうちの1つを制御していると、正直な別の認可サーバーが発行した認可コードやトークンを、自分の認可サーバー宛てにクライアントへ送らせようとします。これがmix-up攻撃で、RFC 9207 Section 1が定義する攻撃類型です。

直感的にはPKCEで防げそうに見えます。ところがセキュリティベストプラクティスの文書は、PKCE単独では防げないと述べています。クライアントがcode_verifierを攻撃者のトークンエンドポイントへそのまま送ってしまうからです。リソースインジケーター(RFC 8707)も、攻撃者の認可サーバーが正直な認可サーバーへのリクエストより先にそれを横取りしている状況では役に立ちません。

iss検証の4つの分岐

仕様が定める緩和策は「Authorization Response Validation」です。クライアントはリダイレクトの前に、選んだ認可サーバーのメタデータからissuerを記録し、PKCEのコード検証子やstateと同じリクエスト単位の記録に結び付けます。認可レスポンスを受け取ったら、認可コードをどのトークンエンドポイントにも送る前に、issパラメーターを次の表に従って検証します。

3行目は、メタデータの更新より先にissを返し始めた認可サーバーを受け入れるための扱いです。最後の行にあるとおり、issを返さず対応も宣言しない認可サーバーに対しては、この検証が働きません。ベストプラクティスの文書も、正直な認可サーバーがissを出すことが前提で、出さないサーバーには保護が及ばないと明記しています。

比較の細部も固定されています。クライアントはissをデコードしたあと、比較の前に正規化してはなりません(MUST NOT)。禁じられるのは、スキームやホストの大文字小文字の統一、デフォルトポートの省略、末尾スラッシュの調整、パーセントエンコーディングの正規化です。不一致のとき、エラーレスポンスのerror・error_description・error_uriも実行や表示の対象にしてはいけません。

認可サーバー側のissの返却は、SHOULDです。仕様は将来の改訂でMUSTへ引き上げる見込みだと書いています。実装者には、今から出力と検証を始めるよう促しています。

2026-07-28版の変更履歴には、この検証の追加(SEP-2468)と並んで、クライアント資格情報が発行元の認可サーバーに紐づくという明確化(SEP-2352)も載っています。永続化した資格情報は発行者の識別子をキーに保存し、別の認可サーバーでは再利用せず、認可サーバーが変わったら再登録することがMUSTです。mix-up攻撃の足場を断つ方向の変更です。

リダイレクトを伴う認可コードフローとは前提が違い、ユーザー操作を介さないマシン間の認可はOAuth Client Credentials拡張が扱います。

代理の混乱(Confused Deputy)をどう断つか

サードパーティAPIへの仲介役として動くMCPサーバーは、Confused Deputy問題の標的になります。攻撃者は盗んだ認可コードを使い、ユーザーの同意を経ずにアクセストークンを取得しようとします。静的なクライアントIDを使うMCPプロキシサーバーは、動的登録されたクライアントごとにユーザー同意を取得することがMUST要件です。サードパーティの認可サーバーへ転送する際に追加の同意が必要になる場合も含みます。

ベストプラクティスの文書は、同意を挟む順序まで示しています。

手順

プロキシサーバーの同意フロー

1. 1

   クライアントが登録される

   MCPクライアントがredirect_uriを添えて登録し、client_idを受け取ります。

2. 2

   MCPサーバー自身の同意画面を出す

   サードパーティの認可サーバーへ転送する前に、client_idごとの承認済みレジストリを確認します。未承認なら、クライアント名・要求されるスコープ・トークンの送り先redirect_uriを示す同意ページを出します。

3. 3

   同意後にサードパーティへ転送する

   承認の保存後に、静的なクライアントIDでサードパーティの認可サーバーへリダイレクトします。コールバックでコードをトークンに交換し、最後にクライアントの登録済みredirect_uriへ戻します。

同意の保存には条件が付きます。Cookieで同意を記録するなら__Host-プレフィックス、Secure・HttpOnly・SameSite=Laxの属性、署名またはclient_id単位の紐づけが必要です。同意ページにはCSRF対策を入れ、frame-ancestorsのCSPディレクティブかX-Frame-Options: DENYでiframeへの埋め込みも防ぎます。stateの追跡Cookieは、ユーザーが同意画面を承認した後にだけ設定します。承認前にセットすると、攻撃者が細工した認可リクエストで同意画面を迂回できるためです。

アクセストークンの権限制限とトークンパススルー

Access Token Privilege Restrictionは、MCPサーバーが他のリソース向けに発行されたトークンを受け入れてしまう脆弱性です。MCPサーバーは、受け取ったアクセストークンが自分宛てであることをリクエスト処理前に検証しなければなりません。audienceクレームに自分が含まれないトークンは拒否します。検証の手順はOAuth 2.1 Section 5.2に従います。

上流APIにリクエストするとき、MCPサーバーは上流に対するOAuthクライアントとして動きます。

くらべる

上流APIへ渡すトークン

MUST NOT

禁止: パススルー

クライアントから受け取ったトークンをそのまま上流APIへ転送します。上流がMCPサーバー発のトークンと取り違える恐れがあります。

MUST

必須: 別トークン

上流の認可サーバーが発行した、上流API専用のトークンを使います。

パススルーが禁じられる理由は、ベストプラクティスの文書が4つ挙げています。

• レート制限やリクエスト検証など、トークンのaudienceに依存する統制をすり抜ける
• 上流のログには、MCPサーバーではない別の主体からのリクエストに見え、監査と調査が難しくなる
• 盗まれたトークンを持つ攻撃者が、検証の甘いサーバーをデータ持ち出しの中継に使える
• 1つのサービスが侵害されると、同じトークンを受け入れる他のサービスへ波及する

当面は単なる中継役のサーバーでも、後から統制を足す余地を残すために、最初からaudienceを分けておく意味があります。

クライアントIDメタデータ文書(Client ID Metadata Document)特有のリスク

2026-07-28版の変更履歴では、OAuth 2.0の動的クライアント登録(RFC 7591)が非推奨になりました。後継はClient ID Metadata Documents(CIMD)です。動的登録は、CIMDに対応しない認可サーバー向けの後方互換として残ります。

CIMDには専用のセキュリティ項目があり、認可サーバーがメタデータドキュメントを取得する際のSSRF(サーバーサイドリクエストフォージェリ)リスクをSHOULDで考慮することを求めます。ここでは、localhostリダイレクトURIの問題を詳しく見ます。

localhostなりすましの手順

メタデータドキュメントが証明するのは、ドメインの管理権限だけです。localhostのどのプロセスが待ち受けているかまでは証明できません。

手順

localhostリダイレクトでのなりすまし

1. 1

   正規クライアントのURLを名乗る

   攻撃者が、正規クライアントのメタデータURLを自分のclient_idとして提示します。

2. 2

   任意のlocalhostポートを指定する

   攻撃者は自分が待ち受けているlocalhostのポートをredirect_uriに指定します。

3. 3

   リダイレクトで認可コードを受け取る

   ユーザーが承認すると、認可コードが攻撃者へ届きます。

認可サーバーが目にするのは正規クライアントのメタデータで、ユーザーの目に映るのも正規クライアントの名前です。見分けがつきにくいことが、この攻撃の厄介な点です。

認可サーバーへの要件は3段階です。localhost限定のリダイレクトURIには追加の警告を出す(SHOULD)。強い保証のために追加の証明手段を求めてもよい(MAY)。認可中はリダイレクト先のホスト名をはっきり表示する(MUST)。

信頼ポリシーの組み方は認可サーバーに委ねられています。ベストプラクティスの文書が挙げる例は次のとおりです。

• 信頼するドメインの許可リスト(保護されたサーバー向け)
• HTTPSのclient_idを広く受け入れる運用(公開サーバー向け)
• 未知のドメインへの評判確認
• ドメインの年齢や証明書による制限

オープンリダイレクト(Open Redirection)はどう防がれるか

認可レスポンスの受け渡しにはリダイレクトが使われます。攻撃者が偽のリダイレクトURIを仕込んで、フィッシングサイトへ誘導する経路も脅威モデルに含まれます。

MCPクライアントは、認可サーバーへリダイレクトURIを事前登録することがMUST要件です。認可サーバー側も、リクエストごとに渡されたURIを事前登録済みの値と厳密に突き合わせることがMUST要件になります。クライアントは認可コードフローでstateパラメーターを使って検証し、元のリクエストと一致しない結果を破棄することがSHOULD要件です。

認可サーバーには、信頼できないURIへユーザーエージェントを誘導しないための対策がMUSTで課されます。自動でリダイレクトするのは、信頼できるURIの場合だけにするのがSHOULDです。信頼できないURIなら、ユーザーに知らせて判断を委ねる選択肢が示されています。

まとめ

自分の実装がmix-up攻撃に耐えるかは、PKCEやresourceの有無ではなく、issを記録済みの発行者と照合しているかで決まります。仲介役のMCPサーバーを作るなら、同意画面とトークンの別発行を先に固めると、Confused Deputyとパススルーの両方を同時に塞げます。