MCP OAuthのtoken audience境界: passthroughが別API権限へ届く条件
MCP clientから受けたtokenとupstream API用tokenは別の認可関係です。resource、audience、検証場所、発行元を分けると、token passthroughが別backendの権限へ到達する経路を接続前に判定できます。
Read in EnglishMCP clientからMCP serverへ渡すaccess tokenと、MCP serverがupstream APIへ渡すaccess tokenは、別の認可関係です。2026-07-28の正式MCP仕様は、clientが認可要求とtoken要求の両方へMCP serverを示すresourceを含めること、serverが自分向けに発行されたtokenだけを受け入れること、clientから受けたtokenをupstreamへ転送しないことを必須としています。1本のBearer tokenを両方のhopで使う構成は、単なる実装簡略化ではなく、別のresourceに与えられた権限がMCP経由で使われる信頼境界の欠落です。
2つの認可関係と検証場所
| 通信hop | 想定するcredential | 必要な境界 | 境界がない場合の含意 |
|---|---|---|---|
| 認可server → MCP client | MCP serverを対象とするtoken | resourceで対象を指定し、発行先を限定 | 別resource向けtokenとの区別が曖昧 |
| MCP client → MCP server | MCP server向けtoken | MCP serverが発行元、有効期限、scope、意図されたaudienceを検証 | 他service向けtokenを入口で受理 |
| MCP server → upstream API | upstream認可serverが発行した別token | MCP serverがOAuth clientとして必要最小scopeを取得 | clientのtokenが別backendまで到達 |
危険な経路は、clientがupstream API向けtokenをMCP serverへ提示し、serverがaudience不一致を拒否せず、そのtokenをAuthorization headerのままupstreamへ転送する場合です。upstreamではtokenが正規に発行されたものなので、そこに含まれる権限で要求が成立する可能性があります。MCP server側のrate limit、入力検証、client識別、監査記録は、そのcredentialの本来の境界を復元できません。侵害された別serviceで得たtokenが複数resourceに受理される構成でも、同じ問題が広がります。
仕様上の必須条件
現行MCP Authorization仕様では、MCP clientは認可要求とtoken要求の両方に、接続対象MCP serverのcanonical URIをresourceとして含めます。MCP serverはresource serverとして受信tokenを検証し、自分のresource向けでないtokenを受け入れたり中継したりしてはいけません。upstream APIへ接続するserverは、そのAPIに対するOAuth clientとなり、upstream認可serverが発行した別tokenを使います。
resourceを送るだけでは、受信側の検証を代替しません。採用確認では、MCP serverが実際にどのissuerとaudienceを許可し、不一致を処理前に拒否するかまでを確認します。scopeが狭くても、tokenの対象resourceが違えば受入れ条件を満たしません。
導入判断に必要なaccess boundary
接続前の実務確認では、次の記録が判断材料になります。これはMCP Guardの推奨する採用記録であり、公式仕様が定める書式ではありません。
- MCP endpointのcanonical URIと、認可・token要求で送られる
resource - MCP serverが許可するissuer、audience、scopeと、不一致tokenの拒否結果
- upstream APIごとのtoken発行元、account、scope、保存先、失効方法
- clientから受けたAuthorization headerをupstream要求へ複製しない実装確認
- 正しいMCP向けtoken、別resource向けtoken、期限切れtokenを分けたnegative test
入口とupstreamでtoken発行元とcredential lifecycleが分離され、各hopの最小scopeが確認できる構成は採用候補です。任意のBearer tokenを受け入れる、audienceを検証しない、または同じtokenを別backendへ転送する構成は、修正と再確認まで接続を見送ります。
確認範囲と出典
2026年9月22日に、stable releaseであるMCP 2026-07-28のAuthorization仕様、同版のSecurity Considerations、公式Security Best Practicesを確認した実務分析です。個別MCP serverの検査結果、実際のtoken漏えい、または特定製品のCVEを示すものではありません。表と採用記録は公開仕様に基づくMCP Guardの実務推奨です。