MCPのEnterprise Authorization拡張 — IdPで一元管理する仕組み

MCPサーバーへのアクセス許可を、社員一人ひとりの個別承認でなく企業のID基盤(IdP)側で一元管理する拡張仕様がEnterprise-Managed Authorizationです。拡張識別子はio.modelcontextprotocol/enterprise-managed-authorization。OktaやAzure ADのようなIdPが「誰がどのMCPサーバーにアクセスできるか」を決定し、MCPクライアントはその判定結果に従うだけになります。

個別承認から企業IdP主導に変わると何が変わるか

標準のMCP認可フローでは、ユーザーがMCPクライアントからMCPサーバーへ接続するたびに、本人がブラウザで個別に承認します。個人利用のコンシューマーアプリなら、自分のデータに何が触れるかを自分で決められるので、この設計が理想的です。

企業では同じ仕組みが摩擦とセキュリティ上の穴になります。公式の拡張ページは、次の4点を挙げています。

• 社員が、業務で使う全MCPサーバーの認可の細部を理解する必要がある
• 各自が個別に承認するため、セキュリティチームが一貫したアクセスポリシーを強制できない
• 新入社員が、数十のサービスを手動で承認しなければならない
• 退職者のアクセスを、サービスごとに個別に取り消す必要がある

この4点はどれも、承認の判断主体が個人であることから生じます。Enterprise-Managed Authorizationは判断主体を企業IdPに移し、社員がメールやSlackと同じ社内アカウントでログインするだけで済む形に変えます。

ID-JAGで認可を受け取る流れ

拡張の中核はIdentity Assertion JWT Authorization Grant(ID-JAG)という新しいトークン種別です。MCPクライアントは企業IdPからID-JAGを取得し、それをMCPサーバーの認可サーバーに提示してアクセストークンと交換します。仕様は次の3段階で組み立てられています。

SAMLでログインした場合は、SAMLアサーションをトークン交換でリフレッシュトークンに替え、それでID-JAGを要求することもできます。

IdPへのトークン交換リクエスト

2段目の要求は、仕様書の例では次の形です。audienceにMCP認可サーバーの発行者識別子、resourceにMCPサーバーの識別子を入れます。

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://auth.chat.example/
&resource=https://mcp.chat.example/
&scope=chat.read+chat.history
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...
&subject_token_type=urn:ietf:params:oauth:token-type:id_token

audienceは必須で、resourceは任意です。resourceを付けるなら、MCPサーバーのResource Identifier(RFC 9728)にする決まりです。SSOの時点でIdPがクライアント認証を求めていたなら、このトークン交換にも求められます。

ID-JAGの中身

IdPが返すID-JAGは、IdPが署名したJWTです。ヘッダーのtypはoauth-id-jag+jwtで、仕様書の例のペイロードは次のとおりです。

{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example",
  "sub": "U019488227",
  "email": "user@example.com",
  "aud": "https://auth.chat.example/",
  "resource": "https://mcp.chat.example/",
  "client_id": "f53f191f9311af35",
  "exp": 1311281970,
  "iat": 1311280970,
  "scope": "chat.read chat.history"
}

audはリクエストのaudienceと、resourceはMCPサーバーの識別子と対応しています。同じ例のレスポンスではexpires_inが300(秒)、token_typeがN_Aです。ID-JAGはAPIを呼ぶためのトークンではなく、アクセストークンと交換するための引換券だと分かります。

MCP認可サーバーへのアクセストークン要求

クライアントはgrant_typeをurn:ietf:params:oauth:grant-type:jwt-bearerにし、ID-JAGをassertionとして渡します。MCP認可サーバーに事前登録されていないクライアントは、Client ID Metadata Documentのhttps URLをクライアントIDに使えます。必要ならprivate_key_jwtで認証もできます。発行されるアクセストークンは、ID-JAGのresourceで指すMCPサーバーだけに使える形に限定する決まりです。例のレスポンスではexpires_inが86400でした。

IdPが判断できる範囲と、見えない範囲

拡張を導入しても、IdPがMCPの通信を見張れるようになるわけではありません。仕様書の安全性の節は、IdPの視野をアクセストークンの発行過程までと限定しています。クライアントとサーバーの間を流れるMCPのトラフィックそのものは、IdPには見えません。

IdPが強制できるのは「どのユーザーが、どのMCPクライアントで、どのMCPサーバーを使えるか」です。サーバー側のOAuthスコープが細かければ、ユーザーが要求できるスコープまで制御できます。仕様書の例では、engineeringグループにはAIコードエディタからソース管理MCPサーバーへの読み取り専用アクセスを、marketingグループには社内ドキュメントアプリへの読み書きアクセスを与えています。

ロール・グループ所属・条件付きアクセスルールを満たさない社員には、IdPがID-JAGを発行しません。クライアントは未認可のサーバー向けトークンを一度も受け取らない設計です。

取り消しも同じ場所に集まります。IdP側でアクセスを外せば、全MCPクライアントに即座に反映され、クライアントごと・サーバーごとの失効作業は要りません。ただしMCPのトラフィックはIdPの視野の外にあるため、サーバー側のログやアクセス制御は別に設計が要ります。この切り分けはMCPセキュリティガイドの観点と重なります。

クライアント・サーバー・認可サーバーの実装項目

拡張への対応は、MCPエコシステムの3つの役割それぞれに実装項目があります。

MCPクライアント側は、まずリクエストの_meta内にあるio.modelcontextprotocol/clientCapabilitiesで拡張への対応を宣言します。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "...",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/enterprise-managed-authorization": {}
        }
      }
    }
  }
}

そのうえで、ユーザーを企業IdP経由でログインさせてIDアサーション(OpenID IDトークンまたはSAMLアサーション)を保存します。サーバーがこの拡張を要求してきたら、ID-JAGへの交換フローに切り替えます。MCP認可サーバーの認可エンドポイントへユーザーをリダイレクトしてはいけない点が、標準フローとの明確な違いです。

管理者がIdPのエンドポイントを組織単位の設定として構成できる必要もあります。多くの企業展開では、IdPのポリシーが登録済みのクライアントにしかサインインを許しません。そのためMCPクライアントもIdPへの事前登録が必要になる可能性が高いと、仕様書は述べています。トークンのスコープはIdP側の制限で標準のMCP認可と変わりうるので、スコープエラーを適切に処理する必要もあります。

MCPサーバー側は、認可メタデータでこの拡張を要求する旨を宣言します。任意ですが、IdP管理者がアクセスポリシーを設定しやすいよう、サーバーのリソース記述子を公開できます。サーバー側でRBACとスコープを設計する具体例は、mcp-grafanaの導入とRBAC設計が参考になります。

MCP認可サーバー側は、IdPのJWKSエンドポイントでID-JAGの署名を検証し、audience・issuer・有効期限を確認します。ID-JAGが運ぶクレームから権限を判定するロジックも自前で実装します。

対応の有無はクライアントが事前に判別できます。認可サーバーのメタデータにあるauthorization_grant_profiles_supportedにurn:ietf:params:oauth:grant-profile:id-jagが含まれていれば、このプロファイルに対応しています。

アカウントの紐付けでは、ID-JAGに必ずsubクレームが入り、emailクレームが入ることもあります。subjectを主識別子として使い、拡張の導入前から存在する既存アカウントとの照合にだけemailをフォールバックに使う、という優先順位が仕様に明記されています。

「拡張」の仕組み — 識別子・オプトイン・互換性

Enterprise-Managed Authorizationは、MCPのコア仕様ではなく「拡張(extension)」という別の仕組みで提供されています。拡張は{vendor-prefix}/{extension-name}という形式の識別子を持ちます。公式拡張はio.modelcontextprotocolというベンダープレフィックスを使い、第三者の拡張は自分が所有するドメインを逆順にしたプレフィックス(com.example/my-extensionのような形)を使います。

拡張は常に無効が既定で、開発者が明示的にオプトインしない限り有効になりません。SDKも、どの拡張を実装するかを自分で選べます。公式扱いになるには、SEP(Extensions Track)の提出、公式SDKでのリファレンス実装、Core Maintainerのレビューを経ます。

更新にCore Maintainerのレビューは必須ではありませんが、後方互換のない変更には既存の識別子を使い回せません。たとえばio.modelcontextprotocol/enterprise-managed-authorization-v2のような新しい識別子を割り当てます。フィールドの削除や名称変更、型変更、既存挙動の意味変更、新しい必須フィールドの追加は、すべて破壊的変更です。

対応クライアントはまだ限定的

クライアントとサーバーの双方が対応を宣言しない限り、拡張は有効になりません。公式のExtension Support Matrixでこの拡張に対応のチェックが付いているのは、Archestra.AIとmcpc MCP CLIの2つです。Claude(web)・Claude Desktop・VS Code GitHub Copilot・Cursor・ChatGPT・Microsoft 365 Copilotなど、主要クライアントの列は空欄です。

マトリクスの注記によると、認証系の拡張(OAuth Client Credentialsとこの拡張)への対応状況は、コアのMCP認可機能(DCRやCIMD)とは別に管理されています。拡張の解説ページも、この拡張には組織のIT部門による対応が必要になることが多いと述べています。導入を考えるなら、自社が使うMCPクライアントが対応を公表しているかを、IdPの対応状況と合わせて確かめることになります。

IdP・クライアント・サーバーの相互運用は議論が続く

ID-JAGのフローは、企業IdP・MCPクライアント・MCPサーバーの認可サーバーという3者が揃って初めて動きます。別々のベンダーが実装するのが普通なので、仕様どおりに書いても細部で食い違いが出ます。

この溝を埋める場は、もともとEnterprise-Managed Authorization Interest Groupでした。IGの憲章は、扱う内容に実装間の相互運用の報告、適合性テストの案、テナント分離・管理者同意・JITプロビジョニング・トークン有効期間といった導入パターン、IdP製品がID-JAGを発行・検証できない箇所の一覧を挙げています。

このIGは2026-08-17にAuthorization IGへ統合され、専用チャンネルの#enterprise-managed-auth-igはアーカイブ済みです。以後の議論は#auth-igのスレッドとAuthorization IGの定例の議題枠で続いています。拡張には対応するWorking GroupかInterest Groupが必要とされており、この役割の統合先はAuthorization IGです。

まとめ

Enterprise-Managed Authorizationは、MCPサーバーへのアクセス可否を、ユーザー個人でなく企業IdPが発行するID-JAGで決める仕組みです。IdPの視野は発行過程までなので、導入前にはIdPの対応状況と、自社が使うクライアントのMatrix上の対応を両方確かめる必要があります。