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

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

MCPサーバーへのアクセスを社員ごとの個別承認でなく企業IdPで一元管理するEnterprise-Managed Authorization拡張の仕組みと実装要件。

読了目安 約9分

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

MCPのEnterprise Authorizationとは何か

標準のMCP認可フローでは、ユーザーがMCPクライアントを使ってMCPサーバーにアクセスするたびに、本人がブラウザで個別に承認します。個人利用のコンシューマーアプリではこれが正しい設計です。自分のデータに何がアクセスするかを、自分でコントロールできます。

企業環境では話が変わります。社員が使うMCPサーバーの数は数十に及ぶこともあり、そのたびに個別承認を求めるのは非現実的です。Enterprise-Managed Authorizationは、この「ユーザー主導の個別承認」モデルの代わりに、企業のIdPを承認の唯一の決定者に置き換えます。社員はメールやSlackと同じ社内アカウントでログインするだけで、IdPが組織のポリシーに基づいてMCPサーバーへのアクセス可否を判断します。

個別承認モデルが企業でつまずく理由

公式ドキュメントは、標準フローが企業で直面する課題を4点挙げています。

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

これらはいずれも、承認の判断主体が「個人」であることに起因します。Enterprise-Managed Authorizationは判断主体をIdPに移すことで、この4点を同時に解消する設計です。

ID-JAGを使った認可フローの仕組み

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

流れは次の順序で進みます。

  1. MCPクライアントがユーザーをIdPへリダイレクトし、ユーザーがログインする
  2. IdPがIDトークンを発行し、クライアントが保存する
  3. クライアントがIDトークンをID-JAGへ交換をリクエストする
  4. IdPがアクセスポリシーを評価し、条件を満たせばID-JAGを発行する
  5. クライアントがID-JAGをMCP認可サーバーに提示し、MCPアクセストークンと交換する
  6. 以降のMCPリクエストはこのアクセストークンで認証される

このフローで重要なのは、ID-JAGの発行時点でIdPがポリシーを評価していることです。ロール・グループ所属・条件付きアクセスルールを満たさない社員には、IdPがID-JAGを発行しません。MCPクライアント自身がアクセス可否を判断することはなく、認可されていないサーバーへのトークンをそもそも受け取れない設計です。

拡張の要点は次の4つにまとめられます。

要素内容
ポリシーの一元管理内容IdP管理者が承認済みMCPサーバーとアクセスポリシーを一箇所で設定する
シングルサインオン内容社員は社内アカウントで一度ログインするだけで済み、サーバーごとの追加承認画面は出ない
ポリシー適用のタイミング内容トークン発行前にIdPが評価するため、クライアントは未認可トークンを受け取らない
一元的な取り消し内容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アサーション)を保存し、サーバーがEnterprise-Managed Authorizationを要求してきたときにID-JAGへの交換フローへ切り替えます。MCP認可サーバーの認可エンドポイントへユーザーをリダイレクトしてはいけない点が、標準フローとの明確な違いです。管理者がIdPのエンドポイントを組織単位の設定として構成できるようにする必要もあります。

MCPサーバー側は、認可メタデータでこの拡張を要求する旨を宣言します。任意ですが、IdP管理者がアクセスポリシーを設定しやすいよう、サーバーのリソース記述子を公開することも推奨されています。

MCP認可サーバー側は、IdPのJWKSエンドポイントに対してID-JAGの署名を検証し、audience・issuer・有効期限を確認します。ID-JAGが運ぶクレーム(スコープやリソース情報)から権限を判定するロジックも自前で実装する必要があります。アカウントの紐付けについては、ID-JAGには必ずsubjectクレームが含まれ、追加でemailクレームが含まれることもあります。subjectを主識別子として使い、拡張導入前から存在する既存アカウントとの照合にのみemailをフォールバックとして使う、という優先順位が仕様に明記されています。

そもそもMCPの「拡張」とは何を指すか

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

拡張が公式扱いになるまでには、SEPプロセス(Extensions Track)を通す必要があります。SEPを提出し、公式SDKのいずれかで最低1つのリファレンス実装を作り、Core Maintainerがレビューして初めて拡張リポジトリへ取り込まれます。さらに、拡張には必ず対応するWorking GroupかInterest Groupが紐付いていなければならないという要件があり、Enterprise-Managed Authorizationの場合はこの役割を担っていたEnterprise-Managed Authorization Interest Groupが2026-08-17付けでAuthorization IGへ統合され、以後はAuthorization IGがその役割を引き継いでいます。

拡張は既定で無効(disabled by default)で、開発者が明示的にオプトインしない限り有効になりません。また拡張は仕様のコア部分とは独立して進化し、更新にCore Maintainerのレビューは必須ではありません。ただし後方互換性のない変更を加える場合は、既存の識別子を使い回さずio.modelcontextprotocol/enterprise-managed-authorization-v2のような新しい識別子を割り当てるルールになっています。フィールドの削除・型変更・既存挙動の意味変更・新しい必須フィールドの追加はすべて破壊的変更とみなされます。

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

拡張はオプトインで、クライアントとサーバーの双方が対応を宣言しない限り有効になりません。公式のExtension Support Matrixで確認できる対応クライアント一覧では、Enterprise-Managed Authorizationへの対応を明記しているのはArchestra.AIのみです。Claude(web)・Claude Desktop・VS Code GitHub Copilot・Cursor・ChatGPTなど主要クライアントには、この拡張への対応チェックが付いていません。

導入を検討する場合は、自社が使うMCPクライアントが対応を公表しているかを個別に確認する必要があります。企業のIT部門が主導してクライアント側の対応を求めるか、対応済みクライアントへの移行を検討する、という組み合わせが現実的な進め方になります。

Authorization IGがID-JAGの相互運用を検証する

拡張仕様が定義するID-JAGフローは、企業IdP・MCPクライアント・MCPサーバーの認可サーバーという3者が揃って初めて動きます。3者を別々のベンダーが実装するケースが大半のため、仕様どおりに書いても相互運用性の細部で食い違いが出ます。

この溝を埋める役割は、もともとMCPコミュニティのEnterprise-Managed Authorization Interest Group(IG)が担っていましたが、このIGは2026-08-17にAuthorization IGへ統合され、専用チャンネルの#enterprise-managed-auth-igはアーカイブ済みです。IdPベンダー・MCPクライアント実装者・MCPサーバー運用者を集め、実際の導入経験を集約し、独立した実装間の互換性ギャップを洗い出す議論は、以後Authorization IG(#auth-ig)で継続されています。仕様書を読むだけでなく、この議論を追うことが、実装時の落とし穴を早期に知る近道です。

MCPのアクセス制御全般をどう設計するかは、MCPセキュリティガイドで扱っています。個々のユーザーが認可するリモートMCPの標準フローとの違いは、リモートMCPのOAuth認証で解説しています。サーバー側でRBACとスコープを設計する具体例はmcp-grafanaの導入とRBAC設計で扱っています。

まとめ

Enterprise-Managed Authorizationは、MCPサーバーへのアクセス可否をユーザー個人でなく企業IdPが一元的に決定する仕組みです。ID-JAGという新しいトークンをIdPが発行し、MCP認可サーバーがそれを検証してアクセストークンを発行する2段階の交換で、シングルサインオンと即時の一元的な取り消しを両立させます。

対応の実装項目はクライアント・サーバー・認可サーバーの3者に分かれており、それぞれが独立して拡張への対応を宣言する必要があります。対応クライアント一覧はまだ薄く、企業導入を検討するチームは自社が使うクライアントの対応状況をExtension Support Matrixで確認するところから始めることになります。

この記事を共有:XはてブLinkedIn

関連する記事

MCP をもっと見る →