MCP proxyのOAuth信頼境界: 動的clientごとの同意とredirect URI
複数の動的MCP clientを1つのupstream OAuth client IDへ集約すると、upstream側の同意だけではclientごとの許可を証明できません。per-client consentとredirect URI完全一致が必要な境界です。
Read in EnglishMCP proxyが多数の動的登録clientを受け入れながら、third-party APIのOAuthでは1つのstatic client IDを共用すると、2つのclient identityが1つに集約されます。upstream認可serverに残る同意cookieはstatic client IDへの同意であり、新しく登録されたMCP clientへの同意ではありません。proxyがclientごとの同意を確認せずupstreamへ転送すると、既存のupstream同意が別のMCP clientにも適用されたように働くconfused deputy境界になります。
identityが集約される場所
| 段階 | upstreamから見えるidentity | proxyが保持すべき境界 | 欠落時の含意 |
|---|---|---|---|
| 正規clientの初回認可 | proxyのstatic client ID | userとMCP client_idに結び付く同意 | upstream同意だけが残る |
| 別MCP clientの動的登録 | 同じstatic client ID | 登録済みredirect_uriとclient identity | 新clientと既存同意を区別不能 |
| upstream認可への転送 | 同じstatic client IDと既存cookie | 転送前のper-client consent | upstreamが同意画面を省略する可能性 |
| proxy callback | proxy共通のupstream callback | stateと元のMCP client・redirect URIの対応 | authorization codeの返送先を誤る危険 |
third-party認可serverは、proxyの内側に何個のMCP clientがいるかを知りません。したがって、providerの同意画面が一度表示されたことだけでは、新しいMCP clientへ同じ権限を渡す根拠になりません。proxyが認可の主体を取り違える点が、通常のOAuth forwardingとconfused deputyを分けます。
現行MCPが求める保護
2026-07-28のAuthorization Security Considerationsは、static client IDを使うMCP proxyに対し、動的登録されたclientごとにuser consentを得てからthird-party認可serverへ転送することを必須としています。公式Security Best Practicesでは、proxy側の同意画面にMCP client名、要求するthird-party scope、登録済みredirect_uriを表示し、userごとの承認済みclient_idを保持する要件が示されています。
認可要求のredirect_uriは、登録済み値との完全一致が必要です。wildcardや部分一致で代替せず、変更時は再登録します。stateは同意後に生成・保存し、callbackで完全一致と一回限りの使用を確認します。これらはupstream providerの同意cookieとは別に、proxyが守るMCP client境界です。
現行Authorization仕様では、未知のclientとの関係にClient ID Metadata Documents、既知の関係にpre-registrationを使い、Dynamic Client Registrationは対応serverでのfallbackとされています。DCRを使うこと自体が脆弱性という意味ではありません。static upstream IDとの組合せでper-client consentが欠けたときに、信頼境界が成立しません。
導入判断に必要な確認記録
採用側では、同意画面の存在だけでなく、どのidentityへ結び付くかを確認します。次はMCP Guardの実務推奨であり、公式仕様が定める保存書式ではありません。
- user、MCP
client_id、登録済みredirect URI、要求scopeを一組にした同意記録 - 未承認client、変更されたredirect URI、再利用
stateをupstream転送前に拒否するnegative test - upstream static client IDと、proxy内の各MCP client identityを対応付ける監査記録
- callbackでauthorization request、
state、同意済みclient、最終redirect先が同じ取引に属する確認
clientごとの同意がupstream転送前に実施され、redirect URIが完全一致し、callback stateが元のclientへ結び付く構成は採用候補です。upstream providerの過去の同意だけに依存する構成は、境界実装と再確認まで接続を見送ります。
確認範囲と出典
2026年9月22日に、stable releaseであるMCP 2026-07-28のAuthorization仕様、同版のSecurity Considerations、公式Security Best Practicesを確認した設計分析です。特定proxyでこの経路が成立したという観測やCVE報告ではありません。表と導入記録は公開仕様から導いたMCP Guardの実務推奨です。