ハーネスの内側: MCPのOAuthの発行者束縛と、なぜプロトコルセキュリティは文字列比較に宿るのか

まず3つの数字を挙げ、その後で説明します。1つ目。OAuthメタデータ文書の発行者フィールドは、たった1本の文字列です。2つ目。この夏、Atlassian、Context7、Home Assistantはいずれも、その文字列が取得元URLと一致しないMCP認可メタデータを実際に配信し、厳格なクライアントは接続を拒否しました。3つ目。いまMCP仕様に入った修正の核心は「文字列を比較し、違えば拒否する」です。仕組みは本当にそれだけです。そして、それで塞がれるのはOAuthでも特に厄介な攻撃の1つ、ミックスアップ攻撃です。MCPのデプロイ形態は、この攻撃を構造的にさらに悪化させます。

これはハーネスの内側の記事なので、配管の中まで入ります。発行者束縛の問題とは何か、どのフローに影響するのか、2026-07-28仕様一式がMCPクライアントやサーバーの実装者へ何を要求するのかを見ます。同じリリースのステートレス転送変更は見出しを取りました。認証強化には6つものSEPがあるのに、ほとんど報じられていません。順番が逆です。実際の認証情報を保持するMCPサーバーを運用しているなら、混乱したクライアントが間違った相手へトークンを渡すかどうかを決めるのはこちらだからです。

要点 - MCPは従来のOAuthの形を反転させます。1つのクライアントが、実行時に発見される多数の認可サーバーと通信します。まさにこの反転した構成こそ、ミックスアップ攻撃が狙うトポロジーです。 - 2026-07-28仕様パッケージには6つのSEPがあります。特に重要なのは2つです。SEP-2468はRFC 9207に従って認可レスポンスのissパラメータを検証し、SEP-2352は登録済みの各クライアント認証情報を、それを発行した発行者へ束縛します。 - これは理論上の話ではありません。この夏、AtlassianとContext7のMCPエンドポイントは発行者が一致しないメタデータを実環境で配信し、厳格なクライアントを壊しました。仕様は、本番ですでに起きている障害へ追いつこうとしています。 - iss検証はいまは推奨ですが、必須化へ向かっています。今日から組み込み、対応すべきサーバーがissを返さない場合も「まあいいか」ではなく拒否扱いにしてください。 - このパッケージを完全に採用しても、強化されるのはクライアントとサーバー間の認証だけです。エージェントID、リクエスト単位の認可、委譲の来歴、監査はプロトコル外に残り、利用者側の責任です。

何が起きたのか

2026年5月21日、MCPメンテナーは2026-07-28仕様のリリース候補を確定し、最終仕様は7月28日に公開されました。SDKメンテナーはそれ以降、10週間の検証期間に入っています。多くの論評はステートレス化に向かいました。しかしその下には、Tigeraによるリリースの詳細分析が整理した通り、OAuth層を強化する6つの仕様拡張提案があります。

運用整理に近い3つのSEP、2207、2350、2351は「明確化」です。しかし認証仕様の明確化は重要です。2つのSDKがメタデータ文書の置き場所について食い違えば、それは脚注ではなく相互運用障害です。それでも荷重を支えるのは2468と2352です。どちらも同じ問いに答えます。クライアントは、いま実際にどのサーバーと話しているのかをどう確認するのか。

MCP 2026-07-28仕様パッケージにはOAuthを強化する6つのSEPがあります。発行者検証（2468）、発行者に束縛された認証情報（2352）、動的クライアント登録でのクライアント種別宣言（837）に加え、リフレッシュトークン（2207）、スコープ累積（2350）、発見動作（2351）が文書化されました。Tigeraの分析によれば、リリース候補は5月21日に確定し、最終仕様は2026年7月28日に公開されました。

脆弱性モデル: 1つのクライアント、多数の発行者

従来のOAuthは、多数のクライアントと1つの認可サーバーを想定します。何千ものアプリが、1つのIDプロバイダー、1つのトークン発行者へつながる形です。クライアントが認可レスポンスを誤ったサーバー由来だと認識させられるミックスアップ攻撃は、多くのクライアントがそもそも1つの発行者としか通信しなかったため、比較的ニッチな懸念でした。

MCPはこれを丸ごと逆向きにします。1つのクライアント、つまりホストアプリケーションが多数のMCPサーバーと通信します。それぞれ別の認可サーバーを前段に持つ可能性があり、実行時に発見され、多くの場合動的クライアント登録でその場で登録されます。仕様の著者は直接こう説明しています。発行者検証SEPが対象とするのは、「MCPの単一クライアント、多数サーバーというデプロイパターンで、より起こりやすいミックスアップ攻撃の一種」です。Tigeraの記事が引用しています。クライアントが同時に12もの認可サーバーへの登録を保持しているなら、攻撃者は暗号を破る必要がありません。レスポンスを間違ったサーバーのものだとクライアントに認識させれば済みます。

形はこうです。エージェントのホストが正規サーバーAとのフロー途中にいるとき、実際には攻撃者が制御するサーバーBからレスポンスが届きます。発行者を確認しなければ、クライアントはBを相手に交換を完了し、認可コードを漏らす可能性があります。あるいはBが発行したトークンを受け入れ、さらに先へ提示するかもしれません。従来型OAuthの修正として2021年に策定されたRFC 9207は、認可レスポンスへ明示的なissパラメータを追加し、期待した発行者以外から来たものをクライアントが拒否できるようにしました。SEP-2468はその要件をMCPへ取り込みます。SEP-2352が扱うのは、より静かな半分、認証情報です。従来は、発行者Aが発行したクライアントIDを保持しているクライアントが、リソース移行後に発行者BへAの認証情報を提示できました。動く場合もありました。しかし認証システムに「たまに動く」は欲しくない特性です。そこで2352は、登録を認可サーバーごとに保持し、発行者値へ束縛し、移行時に再登録するよう要求します。

この攻撃クラスへの対策は今回が最初ではありません。2025-06-18仕様改訂ではリソース指示子（RFC 8707）が必須になり、トークンが特定の1サーバー向けに発行されるようになりました。MCP認可仕様はすでに、別リソース向けのトークンを受け入れることや、そのまま下流へ渡すことを禁じています。2026-07-28パッケージは同じ方向を進めています。デフォルトでの信頼を減らし、明示的な束縛を増やす方向です。私のMCPとAPIの比較を読んでいるなら、これはそこで説明した柔軟性の代償です。実行時発見によってMCPは組み合わせやすくなります。同時に、こうしたID上の問いも自ら生み出します。

MCPの「1クライアント、多数サーバー」というトポロジーは、ミックスアップ攻撃がまさに狙うデプロイパターンです。攻撃者は暗号を破る必要がなく、レスポンスや認証情報を間違った認可サーバーのものだとクライアントに思わせれば済みます。SEP-2468はRFC 9207のissパラメータを使ってレスポンスを発行者へ束縛し、SEP-2352は登録済み認証情報を発行元サーバーへ束縛します。Tigeraの分析とRFC 9207に基づきます。

仕様が本番障害へ追いついている

ここまでが抽象論に聞こえるなら、そうではありません。発行者文字列はこの夏、実際のMCPデプロイで壊れており、厳格なクライアントはすでにその不整合につまずいています。

7月、opencodeクライアントのユーザーはAtlassianのRovo MCPサーバーへのOAuthが発見段階で失敗する問題に遭遇しました。保護対象リソースメタデータはテナント固有の認可サーバーを正しく示していましたが、その場所で配信されるメタデータ文書は、取得元のテナントパスではなく、共有の素の発行者 https://auth.atlassian.comを宣言していました。RFC 8414の3.3節は、issuer値が、.well-knownサフィックスを除いてメタデータ取得に使ったURLと完全一致しなければならないと定めています。そのためopencodeの厳格な検証は正しく拒否し、ログインは完全に停止しました。実環境のエンドポイントで確認されたAtlassian側の仕様準拠バグです。6月にはContext7のMCPエンドポイントでも類似バグがあり、広告された認可サーバーとClerkサブドメイン上のメタデータ発行者が食い違い、公式MCP Go SDKがフローを拒否しました。Home Assistantのメタデータは発行者フィールド自体を省略し、別の形でMCPクライアントを壊しました。

この3件はいずれもミックスアップ攻撃そのものではなく、相互運用障害でした。しかし、そこが重要です。攻撃者の偽サーバーを止めるのと同じ文字列比較が、雑に実装された本物のサーバーも止めます。これまで間違っていても通っていたメタデータに対して、エコシステムはまもなくずっと寛容でなくなります。WorkOSによるミックスアップ攻撃の解説は運用上の問題をうまく示しています。多くのOAuthライブラリでは今もRFC 9207検証がデフォルトで無効です。同記事は、subクレームを全体で一致させるのではなく、確認済み発行者の範囲内でアカウント検索を行っていればCVE-2026-59208を防げたと指摘しています。このCVEへの言及は、私自身が独立検証したものではなくWorkOSの報告として扱うべきですが、防御原則自体はいずれにせよ標準的な実務です。

実環境のMCPデプロイでは、この夏ずっと発行者検証が失敗しています。AtlassianのRovo MCPサーバーは、取得元のテナントURLと一致しない発行者をメタデータで返しました（opencode Issue #39332）。Context7のエンドポイントは、広告した認可サーバーとメタデータに宣言した発行者が異なっていました（Context7 Issue #2723）。Home Assistantは発行者フィールドを完全に省略しました。RFC 8414の3.3節は発行者値が取得URLと完全一致することを要求するため、厳格なクライアントが3件すべてを拒否したのは正しい挙動です。

実装者がやるべきこと

MCPクライアントを保守しているなら、次の4点です。

1. 今日から、すべての認可レスポンスでissを検証してください。 進行中のフローで期待している発行者と一致しなければ拒否します。サーバーがRFC 9207対応を広告しているのにパラメータを省略した場合も拒否してください。仕様は、将来版でiss欠落の拒否が必須になることを明示しています。今から必須扱いにすべきです。

2. 登録状態を認可サーバーごとに分離してください。 すべてのクライアントID、シークレット、リフレッシュトークンを、それを発行した発行者値に紐づけて保存します。リソースの保護対象リソースメタデータが新しい認可サーバーを指し始めたら再登録してください。古い認証情報を使い回してはいけません。

3. 動的クライアント登録でapplication_typeを宣言してください。 SEP-837は、デスクトップやCLIクライアントがデフォルトでweb扱いされ、localhostリダイレクトURIを理由に拒否されるタイプの障害を解消します。1フィールドで、実在するバグの一群が消えます。

4. アカウント検索を発行者の範囲内に限定してください。 subクレームは、実際に検証した発行者の名前空間内だけでアカウントと一致させるべきです。全体検索してはいけません。

MCPサーバー、またはその前段の認可サーバーを運用しているなら、issuerが取得URLと完全一致するメタデータを配信してください。テナントパスも含めます。RFC 9728に従って保護対象リソースメタデータを実装し、トークンが自分のリソース向けに発行されたものか引き続き検証してください。そして増え続けるMCPサーバー群に対してエージェントをセルフホストしているなら、台数計算も重要です。N体のエージェントとM台のサーバーなら、発行者に束縛された登録はN×M件です。エージェント10体なら表計算で済みます。100体ならレジストリが必要です。そして仕様は、そのレジストリについて何も決めません。そこはプラットフォーム側の仕事です。

実装者は、認可レスポンスのissを検証し、不一致や、対応を広告したサーバーでの欠落を拒否する必要があります。認証情報は発行者ごとに分離して保存し、移行時には再登録し、動的クライアント登録ではapplication_typeを宣言し、アカウント検索は検証済み発行者へ限定します。TigeraのSEP分析とWorkOSのミックスアップ対策ガイダンスに基づきます。Tier 1 SDKは仕様の10週間の検証期間内に対応する見込みです。

仕様がまだ答えていないこと

6つのSEPをもう一度見て、共通点に注目してください。すべてが、1つのOAuthクライアントと1つの認可サーバーの間の交換を強化するものです。それは必要でした。しかしTigeraの分析が率直に書いている通り、トークンが認証するのはクライアントであって、エージェントではありません。1つのホストの背後に200体のエージェントがいても、共有されるクライアントIDは1つです。発行者束縛だけでは、そのクライアントの背後にどのエージェントがいて、誰の代理で、何を根拠に判断しているのかは分かりません。スコープは入場許可であって、リクエスト単位のポリシーではありません。委譲チェーン、つまりエージェントがエージェントを呼び、その先でサーバーを呼ぶ構成は、各ホップがOAuth上は正しくても、端から端まで責任追跡不能になり得ます。そしてパッケージのどこにも、それを記録する義務はありません。プロトコルとしては正しいスコープ設定ですが、企業としては不完全な答えです。

だからといって、この作業を軽く見ているわけではありません。発行者検証のないMCPは、証明書チェックのないHTTPに近い状態でした。その穴はいま塞がりつつあります。ただし残る4つの空白、エージェントID、リクエスト単位の認可、委譲の来歴、監査はガバナンス層です。仕様を待っていても届きません。エージェントガバナンスについてクライアントと取り組むときに私が扱うのと同じ空白であり、エージェントを囲む環境が強制するか、誰も強制しないかのどちらかです。

FAQ

MCPのOAuthの発行者束縛問題とは何ですか？

MCPクライアントは実行時に発見される多数の認可サーバーと通信するため、レスポンスや認証情報を誤ったサーバー由来だと認識させられるミックスアップ攻撃に弱くなります。2026-07-28仕様は、認可レスポンスのissパラメータをクライアントが検証すること（SEP-2468、RFC 9207を採用）と、登録済みの各認証情報を発行者へ束縛すること（SEP-2352）でこれを修正します。

これはMCP自体の脆弱性ですか？

MCPのデプロイ形態によって起こりやすくなった脆弱性クラスで、仕様レベルでは今回塞がれました。この夏に本番で見つかった障害、Atlassian、Context7、Home Assistantの発行者不整合メタデータは実装バグです。ただし、検証しないモデルがどれだけ脆かったかをよく示しています。厳格な検証が、いまの基準です。

どのフローが影響を受けますか？

複数の認可サーバーへ登録されたクライアントの認可コードフロー、サーバーをまたぐ動的クライアント登録、リソースが認可サーバー間を移行した後の認証情報利用、.well-known文書によるメタデータ発見が対象です。1サーバーだけのデプロイは元々このリスクの中心ではありません。エージェントが生み出す複数サーバーのトポロジーが問題です。

いつ必須になりますか？

2026-07-28仕様はすでに最終版です。SDK対応は5月のリリース候補確定から10週間の検証期間内に順次入っています。また仕様は、将来版でissのないレスポンスを拒否することが期待されると明記しています。今から作るものでは必須として扱ってください。

結論

OAuthセキュリティの大部分は、結果が重いだけで、作業そのものは退屈な文字列比較です。そしてMCPも、その事実と向き合う段階に来ました。2026-07-28パッケージは5年前のOAuth修正を、1クライアント、多数サーバーという形ゆえに緊急性が高まったプロトコルへ取り込みました。しかも現実のデプロイが、ちょうどその検査で次々と失敗し始めた時期です。SDKを更新し、issを検証し、登録を発行者へ束縛してください。そのうえで、仕様があえて答えなかった正しい問いをしてください。あなたが発行したトークンが、承認するはずのなかったツール呼び出しに使われ、しかも名前すら特定できないエージェントから提示されたとき、誰が検知し、記録はどこに残るのか。その答えは仕様からは出てきません。仕様の周囲に作るハーネスから出てきます。

MCPデプロイの認証とID設計を整理しているなら、これは私がクライアントと定期的に話しているテーマです。お問い合わせください。

情報源

• Tigera、「MCPの認証強化: 6つの新しいOAuth SEPが何を修正し、何をまだ修正しないのか」: https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ （2026年7月28日公開、2026年8月29日取得）

• WorkOS、「OAuthミックスアップ攻撃とRFC 9207: トークン交換まで届かなかった発行者チェック」: https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 （2026年7月20日公開、2026年8月29日取得）

• Model Context Protocol、認可仕様: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization （2025年11月25日公開、2026年8月29日取得）

• RFC Editor、RFC 9207「OAuth 2.0認可サーバー発行者識別」: https://www.rfc-editor.org/rfc/rfc9207.html （2021年12月16日公開、2026年8月29日取得）

• opencodeリポジトリ、Issue #39332「MCP OAuth: Atlassian認証が失敗、RFC 8414の発行者不一致」: https://github.com/anomalyco/opencode/issues/39332 （2026年7月28日公開、2026年8月29日取得）

• Context7リポジトリ、Issue #2723「MCP OAuthエンドポイントのOAuthメタデータ発行者不一致」: https://github.com/upstash/context7/issues/2723 （2026年6月5日公開、2026年8月29日取得）

• Home Assistant Core、Issue #147059、OAuthメタデータの発行者欠落: https://github.com/home-assistant/core/issues/147059 （2025年6月17日公開、2026年8月29日取得）

• modelcontextprotocol/modelcontextprotocolリポジトリ: https://github.com/modelcontextprotocol/modelcontextprotocol （2026年8月29日取得）