MCP 2026-07-28 の認可：発行者の検証とクライアント登録の変更

概要

2026年10月25日時点の情報である。2026-07-28 の認可に関する変更は、発行者の検証、登録、認証情報の帰属に関わる。展開前に、対象リビジョンの認可仕様、登録ルール、認可サーバーのメタデータを再確認する。Client ID Metadata Documents（CIMD）はこのリビジョンで初めて導入されたものではない。2025-11-25 の変更履歴ですでに推奨されている。新リビジョンでは Dynamic Client Registration（DCR）が正式に非推奨となるが、互換性のために残される。

MCP サーバーは保護対象のリソースであり、MCP クライアントがアクセスを取得し、認可サーバーがトークンを発行する。そのため、すべてを同じ運用者が管理していても、変更箇所は複数のサービスに分かれることがある。MCP の OAuth フレームワークは HTTP でのデプロイに適用されるものであり、stdio 向けに規定された認証情報の仕組みではない。

重要な理由

認可フローは、開始時に選択した発行者との関連付けを維持しなければならない。そうしなければ、エンドポイントの変更や曖昧な登録記録により、誤った認可サーバーで認証情報が使われるおそれがある。CIMD では、ドキュメントの取得とリダイレクトの検証も必要になる。URL 形式のクライアント識別子を認識できることは、そのアプリケーションを信頼できる根拠にはならない。

適用方法

• コードを交換する前に認可応答を検証する。 クライアントは、検証済みサーバーメタデータに含まれる発行者を、その認可試行の PKCE verifier とともに記録する。認可サーバーは iss を返すことが推奨され、返す場合は対応していることを宣言しなければならない。クライアントは返された iss をフォームデコードした後、URL の正規化を行わず、記録した値と完全一致で比較する。不一致はエラー応答でも拒否する。メタデータで発行者パラメーターへの対応を宣言しているのに iss がない場合は拒否する。対応の宣言も値の送信もない場合は、仕様上、処理を進めることが認められている。
• 登録認証情報を発行者に結び付ける。 事前登録または DCR で取得した認証情報は、発行元サーバーの識別子に関連付けて永続化する。別の発行者で再利用してはならない。新しいサーバーでは登録を行い、事前登録の発行者が一致しない場合はエラーを示す。このルールによって、自己ホストする CIMD 識別子が特定の発行者専用になるわけではない。登録仕様では、その URL 識別子を再登録なしで別の発行者でも利用できることを明示している。
• 登録方式の選択ルールに従う。 利用可能な事前登録を優先し、次に client_id_metadata_document_supported で対応が宣言されている場合は CIMD を使い、最後に互換性のためのフォールバックとして対応済みの DCR を使う。CIMD ドキュメントはパスを持つ HTTPS URL を使用し、client_id、client_name、redirect_uris を含む。client_id はドキュメントの URL と一致しなければならない。JSON を検証し、要求されたリダイレクトがドキュメントに適合することも検証する。
• メタデータ取得の防御を強化する。 クライアントドキュメントの取得時には、文書で示されたサーバーサイドリクエストフォージェリ対策を適用する。ドメインの信頼ポリシーも検討する。CIMD だけでは localhost へのリダイレクトを利用したなりすましは防げない。要件に従い、認可時にリダイレクト先のホスト名を表示する。
• 従来の DCR も正しく実装する。 クライアントは適切な application_type を指定しなければならない。ネイティブのデスクトップ、CLI、localhost アプリケーションでは native、リモートのブラウザーアプリケーションでは web を使うべきである。登録失敗を見かけ上解消するためにリダイレクトの検査を緩めず、原因を調査する。
• 既存の最低限のセキュリティ要件を維持する。 メタデータで PKCE 対応を確認し、保存トークンを保護し、受け取ったトークンがこの MCP リソースを対象としていることを検証する。上流 API の呼び出しには、上流向けに別途発行されたトークンが必要である。登録方式の移行によって、トークンのパススルーや同意確認の廃止が許されるわけではない。

落とし穴

DCR がすでに削除されたと説明してはならない。また、CIMD は対応が推奨されているのであり、あらゆる場合に必須と説明してはならない。受け入れテストの提案として、ステージングで発行者が正しい応答、不一致の応答、発行者が欠けた応答、発行者の変更、維持する各登録方式を試す。拒否した応答がコード交換に進まないことを確認する。これらはプロトコルへの適合性を確認するものであり、特定の認可環境に対するセキュリティ監査ではない。