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

MCP認可仕様の「Security Considerations」章は、OAuth 2.1のセキュリティベストプラクティスを土台にしながら、MCP固有の脅威をトークン窃取・認可コード保護・mix-up攻撃・Confused Deputy問題という個別のMUST/SHOULD要件に分解しています。OAuth認可フローの手順そのものではなく、仕様が名指しする脅威モデルの中身だけを追います。

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

MCP認可のセキュリティ要件は、独自に一から定義されたものではありません。仕様は冒頭で、実装者がOAuth 2.1のSection 7「Security Considerations」に従うことをMUST要件として明記し、その上でMCP固有の脅威に対する追加要件を積み重ねる構成を取ります。章立ては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の9項目です。OAuth 2.1という一般論の上に、MCP特有の状況(複数の認可サーバーとやり取りする・サードパーティAPIの仲介役になる)で顕在化する脅威を積み上げる構成になっています。

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

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方式は事実上締め出されています。

PKCEのサポートを認可サーバーがどう広告しているかも仕様は具体的に定めます。OAuth 2.0 Authorization Server Metadataでcode_challenge_methods_supportedが欠けている場合、MCPクライアントはPKCE非対応と判断し、認可処理を進めることを拒否しなければなりません。OpenID Connect Discovery経由の場合も同様で、このフィールドが無ければ処理を拒否するMUST要件が課されています。

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

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

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

直感的にはPKCEで防げそうに見えますが、仕様は明確にこれを否定します。PKCEのcode_verifier自体を、クライアントが攻撃者のトークンエンドポイントへそのまま送ってしまうため、PKCEは単独ではmix-up攻撃を防げません。リソースインジケーター(RFC 8707)も同様に無力です。攻撃者の認可サーバーが正直な認可サーバーへのリクエストより先にリクエストを横取りしている場合、宛先を指定するパラメーターそのものが攻撃者の手中にあるためです。

仕様が示す唯一の緩和策は「Authorization Response Validation」です。クライアントがリダイレクトする前に記録しておいた認可サーバーの情報とレスポンスを突き合わせ、認可コードが意図しないトークンエンドポイントで交換されるのを防ぎます。この緩和策には前提があります。正直な認可サーバーがiss(発行者)パラメーターを確実に返すことが条件で、issを返さない正直なサーバーに対しては、この対策自体が機能しません。この攻撃はブラウザリダイレクトを伴う認可コードフローに特有です。リダイレクトを使わないOAuth Client Credentials拡張はこの経路自体を持たないため、mix-up攻撃の対象外になります。

代理の混乱とトークン権限の制限(Confused Deputy / Access Token Privilege Restriction)

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

Access Token Privilege Restrictionは、MCPサーバーが他のリソース向けに発行されたトークンを受け入れてしまう脆弱性です。MCPサーバーは、受け取ったアクセストークンが自分宛てに発行されたものであることをリクエスト処理前に検証しなければならず、audienceクレームに自分が含まれないトークンは拒否しなければなりません。上流APIへリクエストする際も、クライアントから受け取ったトークンをそのまま転送すること自体がMUST NOT要件で禁止されています。上流APIで使うトークンは、上流の認可サーバーが発行する別個のトークンでなければなりません。

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

2026-07-28版の仕様は、Client ID Metadata Documents(CIMD)という新しいクライアント登録方式に、専用のセキュリティ考慮事項を追加しました。認可サーバーがメタデータドキュメントを取得する際のSSRF(サーバーサイドリクエストフォージェリ)リスク、localhostのみのリダイレクトURIがなりすましを防ぎきれない問題、ドメイン単位の信頼ポリシーをどう設計するか、の3点です。

localhostリダイレクトURIについては、CIMDの仕組みだけではlocalhostURLのなりすましを防げないと仕様が明記しています。認可サーバー側には、localhost限定のリダイレクトURIに追加の警告を表示することがSHOULD要件として、認可中はリダイレクト先のホスト名を明確に表示することがMUST要件として求められます。

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

認可レスポンスの受け渡しにはリダイレクトが使われるため、攻撃者が偽のリダイレクトURIを仕込んでフィッシングサイトへ誘導する経路も脅威モデルに含まれます。MCPクライアントは認可サーバーへリダイレクトURIを事前登録することがMUST要件で、認可サーバー側もリクエストごとに渡されたURIを事前登録済みの値と厳密に突き合わせることがMUST要件です。クライアントには、認可コードフローでstateパラメーターを使い検証すること、元のリクエストと一致しない結果を破棄することがSHOULD要件として求められます。認可サーバーは、信頼できないURIへユーザーエージェントを自動リダイレクトしないことがMUSTで、信頼できないURIの場合はユーザーに知らせて判断を委ねる選択肢が示されています。

この脅威モデルはOAuthフローのどの段階に効くか

仕様が定義する脅威は、認可フローの単一の弱点に集中しているわけではなく、段階ごとに異なる攻撃面を持ちます。

実際のOAuth認可フローが7段階に分かれてどう進むか、Claude Codeがどう実装を積み重ねてきたかはリモートMCPのOAuth認証に譲ります。ここで示した脅威モデルは、その各段階のどこに落とし穴があるかを仕様原文の側から補う地図です。サーバー接続前の信頼判断そのものはMCPセキュリティガイドが扱っています。

まとめ

MCP認可のSecurity Considerations章が定義する脅威は、単一の攻撃ではなく、認可フローの各段階に対応する複数の攻撃類型の集合です。mix-up攻撃はPKCEやリソースインジケーターでは防げず、iss検証というピンポイントの対策に依存します。トークン窃取は保存方法と有効期限の短さで軽減し、Confused Deputyはトークンのパススルー禁止で断ち切ります。

MCPクライアント・サーバーを実装する側にとって、この章はOAuth 2.1の一般論をMCP固有の状況に翻訳したチェックリストとして機能します。どのMUST要件を満たせていないかを洗い出すところから、実装の見直しが始まります。