🔐 技術調査 - MCP Enterprise-Managed Authorization (EMA)

MCP (Model Context Protocol) を企業に広げるとき、最大のボトルネックは「ユーザーが MCP サーバーごとに個別 OAuth 認可する」方式でした。Enterprise-Managed Authorization (EMA) は、企業の IdP (Identity Provider) を認可の決定主体に据え、従業員が 1 回 SSO ログインするだけで承認済みの全 MCP サーバーへ自動接続できるようにする MCP 拡張です。2026-06-18 に stable 版が公開されました。

本記事では、EMA の位置づけ・アーキテクチャ (C4 モデル)・ID-JAG (Identity Assertion JWT Authorization Grant) のデータ構造・IdP / サーバー / クライアント各層の構築手順・運用・セキュリティ考慮事項までを、公式仕様と Okta / Atlassian の実装事例をもとに整理します。

調査日: 2026-07-07 / 対象: MCP 拡張 io.modelcontextprotocol/enterprise-managed-authorization (2026-06-18 stable 公開)

概要

Enterprise-Managed Authorization (EMA) は、MCP の拡張仕様です。拡張 ID は io.modelcontextprotocol/enterprise-managed-authorization です。2026-06-18 に stable 版として公開されました。

MCP の標準的な認可モデルでは、ユーザーが MCP サーバーごとに個別に認可します。この方式は個人利用には適しています。一方、企業環境では次の課題を生みます。

• 従業員が、利用する MCP サーバーごとの認可手順を理解する必要があります
• セキュリティチームが、ユーザー個別の認可では一貫したアクセスポリシーを強制できません
• 入社時に、従業員が数十個のサービスを手動で個別認可する必要があります
• 退職時に、サービスごとに個別のアクセス取り消しが必要になります

EMA は、企業の IdP (Identity Provider) を認可の決定主体に据えることで、この課題を解決します。IdP (Okta・Entra ID・Auth0 など) が、従業員がどの MCP サーバーにアクセスできるかを、組織ポリシーに基づいて決定します。従業員は、メールや Slack など他の業務ツールと同じ企業クレデンシャルで認証します。

位置づけ

EMA は、単独の新規プロトコルではありません。既存仕様の組み合わせとして設計されています。

EMA は、これらの既存要素を「MCP という具体的なユースケース」に当てはめたプロファイルです。新しいトークン形式や新しい信頼モデルを発明したものではありません。

従来方式との比較

補足が 2 点あります。

• 実行時コスト: EMA はサーバー接続ごとに「ID-JAG 取得」「トークン交換」の 2 リクエストを IdP と Authorization Server に対して行います。ユーザー操作は減る一方、ID-JAG が短命 (仕様の例で 300 秒) のため、トークン再取得時にも同じ 2 リクエストが発生します
• 移行時の共存: 既存の個別 OAuth 認可済みユーザーがいる状態から EMA へ切り替える際の再認可要否・共存ルールは公式未明示です。サーバー側のアカウント連携 (sub 主キー + email フォールバック) が既存アカウントとの橋渡しを担います

ユースケース別の推奨

対応エコシステム (2026-06-18 時点)

MCP 公式の client-matrix ページでは、コミュニティ管理の対応表として Archestra.AI の対応のみが明記されています。上記の Claude/Claude Code/Cowork/VS Code の対応状況は、Anthropic および Model Context Protocol 公式ブログ (2026-06-18) の発表内容に基づきます。

特徴

• IdP が MCP サーバーへのアクセス可否をポリシーとして一元管理します
• 従業員は企業クレデンシャルで 1 回 SSO するだけで、承認済みの全 MCP サーバーに接続されます
• IdP がトークン発行前にグループ・ロール・条件付きアクセスルールを評価します
• アクセス権を取り消すと、新規の ID-JAG / アクセストークン発行が IdP レベルで即座に止まります (発行済みトークンの扱いは「アクセス失効」で後述)
• 拡張はオプトインです。クライアントは initialize リクエストで、サーバーは Authorization Server メタデータで対応を宣言し、双方が対応した場合のみ有効になります
• 個人アカウントと業務アカウントの混在を防ぎ、業務アカウントのみの利用を強制できます
• ID-JAG トークンは sub (安定識別子) と任意の email claim を持ち、サーバー側の既存アカウントとの紐付けに使えます

構造

MCP Enterprise-Managed Authorization (EMA) のアーキテクチャを、C4 model の 3 段階 (システムコンテキスト図・コンテナ図・コンポーネント図) で図解します。あわせて認可フロー全体のシーケンス図と、通常の MCP Authorization フローとの構造差を示します。

システムコンテキスト図

EMA を取り巻く関係者と外部システムの関係です。

コンテナ図

EMA を構成する 4 つのコンテナと、ID-JAG・アクセストークンの流れです。

コンポーネント図

各コンテナをドリルダウンした構成です。実装例として Okta Cross App Access (XAA) を Enterprise IdP、Atlassian Rovo MCP Server を MCP Resource Server、Claude や VS Code を MCP Client に当てはめています。

MCP Client (例: Claude Desktop、VS Code GitHub Copilot)

Enterprise IdP (例: Okta Cross App Access)

MCP Authorization Server (例: Atlassian の OAuth 基盤)

MCP Resource Server (例: Atlassian Rovo MCP Server)

補足として、MCP Authorization Server と MCP Resource Server は同一ベンダーが一体で提供する構成もあります。Atlassian の実装では、両者は Atlassian 側の OAuth 基盤としてまとめて提供されています。

EMA 認可フロー シーケンス図

公式ページに掲載されたシーケンス図を正として図解します。

シーケンス図は成功パスを示します。失敗時の分岐は以下です。

通常フローとの構造差

通常の MCP Authorization フロー (2025-11-25 仕様) は、MCP サーバーごとに 401 応答を起点としたブラウザ同意を要求します。EMA はこの起点を Enterprise IdP でのポリシー評価に置き換えます。

データ

概念モデル

EMA に登場するエンティティは、発行元となる 3 つのシステムに所属します。Enterprise IdP は ID Token / ID-JAG / アクセスポリシーレジストリを所有します。MCP Authorization Server は MCP Access Token とその発行条件を宣言するメタデータを所有します。MCP Resource Server は Protected Resource Metadata を所有します。

Enterprise IdP

MCP Authorization Server

MCP Resource Server

情報モデル

ID-JAG (Identity Assertion JWT Authorization Grant)

ID-JAG の header/claims は IETF draft draft-ietf-oauth-identity-assertion-authz-grant-04 で定義されています。MCP の EMA 仕様は、この draft を MCP のコンテキストに適用したものです。

header

payload claims

MCP 仕様の例で実際に使われているのは jti / iss / sub / email / aud / resource / client_id / exp / iat / scope です。それ以外の任意クレーム (sub_id / authorization_details / act / tenant / acr / amr / aud_tenant / aud_sub) は IETF draft では定義されていますが、MCP 仕様の例には登場しません。

Token Exchange Request (ID-JAG 取得)

grant_type は urn:ietf:params:oauth:grant-type:token-exchange (RFC 8693) 固定です。

ID-JAG Token Exchange Response

IETF draft Section 4.3.4 で定義されています。

MCP Access Token Request (ID-JAG から Access Token への交換)

grant_type は urn:ietf:params:oauth:grant-type:jwt-bearer (RFC 7523) です。urn:ietf:params:oauth:grant-type:token-exchange ではありません。 ID-JAG を IdP から取得する際と、ID-JAG を MCP Access Token に交換する際とでは grant_type が異なります。

MCP Access Token (レスポンス)

発行された Access Token は、ID-JAG の resource クレームで示された MCP Server にオーディエンス制限されなければなりません (MUST)。これは MCP EMA 仕様が明記する制約です。

IdP アクセスポリシーレジストリ

IdP は「承認済み MCP サーバーの一覧」と「サーバーごとのアクセスポリシー (グループ / ロール / 条件付きアクセス)」を管理し、Token Exchange Request のポリシー評価に用います。管理者は既存の ID 管理コンソールでこれらを設定します。具体的なスキーマは MCP 仕様・IETF draft のいずれにも定義がなく、仕様未規定です (IdP 実装依存)。

Protected Resource Metadata / Authorization Server Metadata

EMA / ID-JAG 固有の対応宣言は、Authorization Server Metadata の authorization_grant_profiles_supported フィールドで行われます。Protected Resource Metadata 自体には EMA 固有のフィールドはなく、基本 MCP Authorization 仕様 (2025-11-25 版) のフィールドがそのまま使われます。

MCP Client は、この authorization_grant_profiles_supported フィールドを確認することで、接続先の MCP Authorization Server が ID-JAG プロファイルに対応しているかを判定します。

MCP Client 側の宣言

MCP Client は initialize リクエストの capabilities.extensions に、拡張 ID をキーとした空オブジェクトを含めて EMA サポートを宣言します。

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/enterprise-managed-authorization": {}
    }
  }
}

構築方法

MCP Enterprise-Managed Authorization (EMA) の導入には 3 者の作業が必要です。

IdP 側 (Okta Cross App Access) のセットアップ

Okta では EMA を Cross App Access (XAA) として提供します。Claude Enterprise 向け beta ガイド (Okta 公式サポート記事) の前提条件は以下です。

• Anthropic 承認済みの Claude Enterprise-managed auth (EMA) beta 参加組織であること
• Okta Identity Engine (OIE) で XAA 対応が有効化されていること
• Okta テナントのスーパー管理者アカウント
• Claude および対象 MCP (Figma、Asana 等) 用の SAML アプリが Okta に構成済みであること

セットアップ手順は 3 段階です。

手順 1: MCP resource app の XAA 有効化

• Admin Console で Applications > Applications から対象 MCP アプリを選択します
• Resource Server タブで「Enable XAA」をチェックします
• Anthropic から提供される Issuer URL を入力して保存します

汎用の resource app 登録 (Okta developer blog の手順) では、Applications > Applications から App Catalog (Browse App Catalog) で「XAA Resource App」を探して追加し、自組織の Authorization Server の issuer URL を入力します。

手順 2: SAML アプリの設定確認 (カスタムアプリの場合)

• Sign On タブで Application username format を確認します
• SAML Settings で Name ID Format を EmailAddress に設定します

手順 3: AI Agent の登録と接続許可 (ポリシー設定)

Directory > AI Agents > Register Manually で AI エージェント (Claude) を登録します。

この Resource Connections が「どのクライアントがどの MCP サーバーにアクセスできるか」の中央ポリシーになります。IdP はグループメンバーシップ・ロール・条件付きアクセスルールを評価し、ポリシーを満たさないユーザーには ID-JAG を発行しません。

補足: 本番 Okta テナントなしで挙動を試す場合は、Okta が提供する playground xaa.dev を利用できます。アカウント登録は不要です。Developer > Register Client でクライアントを登録すると、Client ID / Client Secret などの認証情報が発行されます。

MCP サーバー側 (Authorization Server) の実装

MCP サーバー側では、既存の Authorization Server に「ID-JAG を受理する grant type」を追加します。公式 Implementation guide が求める実装ポイントは以下です。

1. token endpoint での ID-JAG 検証

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer で送られてくる ID-JAG (JWT) を検証します。Okta developer blog と Atlassian 実装事例 (Rovo MCP) が挙げる検証項目は以下です。

• JWT 署名を enterprise IdP の JWKS エンドポイントの公開鍵で検証する
• typ ヘッダーが oauth-id-jag+jwt であることを確認する
• iss claim が信頼済み IdP の issuer と一致することを確認する
• aud claim が自 Authorization Server の issuer 識別子と一致することを確認する (仕様上 MUST)
• ID-JAG 内の client_id が、交換を試みているクライアントと一致することを確認する (クライアント連続性)
• 有効期限 (exp) とトークンの一意性 (jti) を確認する

検証後に発行するアクセストークンは、resource claim が示す MCP サーバーに audience 制限しなければなりません (仕様上 MUST)。

上記の検証項目を反映した実装案です (公式サンプルではありません。jose ライブラリの標準 API で構成しています)。

// 実装案: Node.js (jose) での ID-JAG 検証例
import { createRemoteJWKSet, jwtVerify } from 'jose';

const idpJwks = createRemoteJWKSet(
  new URL('https://acme.idp.example/.well-known/jwks.json'),
);

async function verifyIdJag(assertion, expectedClientId) {
  const { payload } = await jwtVerify(assertion, idpJwks, {
    typ: 'oauth-id-jag+jwt',                 // typ ヘッダーの検証
    issuer: 'https://acme.idp.example',      // 信頼済み IdP の issuer
    audience: 'https://auth.chat.example/',  // 自 Authorization Server の issuer 識別子
  });
  if (payload.client_id !== expectedClientId) {
    throw new Error('client_id mismatch');   // クライアント連続性の確認
  }
  // jti の一意性検証: 使用済み jti を exp まで保持し、重複した提示を拒否する
  // (仕様は一意性の確認を求めるが、保存方式は未規定)
  return payload;
}

2. IdP claim から権限へのマッピングとアカウントリンク

• ID-JAG の scope / resource claim を自サーバーの認可ロジックに対応付けます
• sub claim を主たる安定識別子としてユーザーを解決します
• EMA 導入前から存在するアカウントとの照合には email claim にフォールバックします

Atlassian の事例では「Resource Authorization Server が外部ベアラートークンを直接信頼することはできない」として、外部アサーション (ID-JAG) を検証した後に Atlassian ネイティブのアクセストークンを発行する二段階モデルを採用しています。外部の sub は IdP ローカル ID・メールアドレス・テナントスコープ識別子など複数形式があり得るため、確実なユーザーマッピングの設計が実装上の要点です。

3. メタデータでの EMA サポート宣言

• Authorization Server metadata の authorization_grant_profiles_supported に urn:ietf:params:oauth:grant-profile:id-jag を含めて宣言します (IETF draft Section 7.2)

{
  "issuer": "https://auth.chat.example",
  "authorization_endpoint": "https://auth.chat.example/authorize",
  "token_endpoint": "https://auth.chat.example/token",
  "authorization_grant_profiles_supported": [
    "urn:ietf:params:oauth:grant-profile:id-jag"
  ]
}

• MCP 公式ガイドは「サーバーの authorization metadata で拡張を宣言し、クライアントに enterprise-managed フローの利用を示す」ことを求めています。PRM (Protected Resource Metadata) 側の専用フィールド名は公式未明示です
• 任意で、enterprise 管理者が IdP 管理コンソールでポリシー設定できるよう、サーバーの resource descriptor を IdP admin API に公開します

MCP クライアント側組織のセットアップ

Claude (Enterprise / Team)

• Anthropic の EMA beta 承認を受けた組織が対象です (2026-07 時点)
• Claude は shared MCP layer で EMA を実装しており、Claude / Claude Code / Cowork で利用できます
• 組織側の作業は前述の Okta beta ガイドの手順 (SAML アプリ + AI Agent 登録 + Resource Connections) です
• Claude 管理画面側の設定項目名は公式未明示です (beta ガイドは Okta 側手順のみ記載)

VS Code (v1.123 以降)

VS Code 1.123 (2026-06-03 リリース) で enterprise-managed MCP 認証がプレビュー提供されました。release notes は対応 IdP の例として Entra ID / Okta / Auth0 を挙げています。

• 管理者: ポリシー管理設定 mcp.enterpriseManagedAuth.idp で IdP を構成します。配信経路は Windows Group Policy / macOS managed preferences / Linux /etc/vscode/policy.json です
• ユーザー (またはサーバー定義): mcp.json の対象サーバーの oauth ブロックに "enterpriseManaged": true を指定します。このフラグがあると VS Code は per-server 登録の標準フローではなく XAA プロバイダー経由でルーティングします

{
  "servers": {
    "my-mcp-server": {
      "url": "https://mcp.example.com/mcp",
      "oauth": {
        "enterpriseManaged": true
      }
    }
  }
}

MCP クライアント実装の共通要件 (公式 Implementation guide)

自作クライアントを EMA 対応させる場合の要件は以下です。

1. initialize リクエストでサポートを宣言します (「■データ > MCP Client 側の宣言」参照)
2. SSO をサポートし、ログイン時に発行される Identity Assertion (OpenID ID Token または SAML assertion) を保存します
3. サーバーが enterprise-managed auth を要求したら、保存済み Identity Assertion で IdP から ID-JAG を取得し、MCP Authorization Server のアクセストークンと交換します。ユーザーを MCP Authorization Server の authorization endpoint にリダイレクトしません
4. enterprise IdP のエンドポイントを組織レベル設定として構成できるようにします
5. IdP 発行トークンの scope 制約を尊重し、scope エラーを適切に処理します

利用方法

必須パラメータ一覧

EMA の実行時 HTTP フローは 2 つのリクエストで構成されます。

リクエスト 1: IdP token endpoint への ID-JAG 取得 (Token Exchange, RFC 8693)

クライアント認証は、IdP 登録時に設定した標準の OAuth クライアント認証方式 (client_secret / private_key_jwt 等) に従います。仕様の例は client_secret を示していますが、方式自体は EMA 固有の規定ではありません。

リクエスト 2: MCP Authorization Server token endpoint での交換 (JWT Bearer, RFC 7523)

ID-JAG 取得の HTTP 例 (仕様原文より)

リクエスト:

POST /oauth2/token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

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
&client_id=2ec954a1d60620116d36d9ceb7
&client_secret=a26d84873504215a34a86d52ef5cd64f4b76

レスポンス:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:id-jag",
  "access_token": "eyJhbGciOiJIUzI1NiIsI...",
  "token_type": "N_A",
  "scope": "chat.read chat.history",
  "expires_in": 300
}

発行される ID-JAG の中身 (デコード後) は以下です。sub がユーザー、client_id が要求クライアント、aud が交換先 Authorization Server、resource が最終アクセス先 MCP サーバーを表します。

{
  "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"
}

Token Exchange の HTTP 例 (仕様原文より)

ID-JAG を MCP Authorization Server のアクセストークンに交換します。

リクエスト:

POST /oauth2/token HTTP/1.1
Host: auth.chat.example

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOiJIUzI1NiIsI...
&client_id=https://client.example.com/client.json

レスポンス:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "token_type": "Bearer",
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "expires_in": 86400,
  "scope": "chat.read chat.history"
}

以降、クライアントはこのアクセストークンを Authorization: Bearer ヘッダーに載せて MCP サーバーを呼び出します。

クライアント実装コード例 (Okta 公式 blog より)

TypeScript (openid-client ライブラリ) での ID-JAG 取得実装です。

private async exchangeIdTokenForIdJag(
  config: openidClient.Configuration,
  idToken: string,
  authServerUrl: string,
  resourceUrl: string,
  scope: string[],
): Promise<string> {
  const tokenExchangeParams = {
    requested_token_type: 'urn:ietf:params:oauth:token-type:id-jag',
    audience: authServerUrl,
    resource: resourceUrl,
    subject_token: idToken,
    subject_token_type: 'urn:ietf:params:oauth:token-type:id_token',
    scope: scope.join(' '),
  };

  const tokenExchangeResponse = await openidClient.genericGrantRequest(
    config,
    'urn:ietf:params:oauth:grant-type:token-exchange',
    tokenExchangeParams,
  );

  return tokenExchangeResponse.access_token;
}

Okta のサンプルリポジトリ (okta-xaa-dev-mcp-client-example) では、この 2 段階交換を withCrossAppAccess() ミドルウェアが自動処理します。.env に IDP_URL / CLIENT_ID / CLIENT_SECRET を設定して起動すると、IdP ログイン後に MCP サーバーへ自動接続されます。

エンドユーザーから見た利用体験

MCP 公式ブログはこの体験を「ログインすると全 MCP コネクタが自動セットアップされる」ゼロタッチセットアップと表現しています。Atlassian の事例でも、管理者が接続を事前承認していれば、ユーザーは Claude にログインするだけで Rovo MCP を追加同意なしに利用できます。

運用

EMA 導入後の運用は、IdP 管理コンソールでの設定変更と、失効・監査・トークン寿命の管理に分かれます。

IdP レジストリの運用

• IdP は「承認済み MCP サーバーのレジストリ」と「サーバーごとのアクセスポリシー」を保持します。
• 管理者は既存の ID 管理ツール上でこのレジストリを設定します。
• MCP サーバーを追加するときは、次の情報を IdP に登録します。

• MCP クライアントも IdP に事前登録が必要です。IdP ポリシーは「事前登録済みクライアントへのサインインのみ許可する」ため、未登録クライアントはサインインの入口で弾かれます。
• ポリシー変更 (グループ追加・スコープ変更など) は IdP 側で完結します。MCP クライアント・サーバー側の再設定は不要です。
• MCP サーバーを廃止・削除する場合は、IdP レジストリから該当エントリを削除します。以降、新規の ID-JAG 発行リクエストは当該サーバーに対して拒否されます。
• 接続先 MCP Authorization Server の EMA 対応は、Authorization Server metadata で確認できます。

curl -s https://auth.chat.example/.well-known/oauth-authorization-server \
  | jq '.authorization_grant_profiles_supported'
# ["urn:ietf:params:oauth:grant-profile:id-jag"] が含まれれば EMA (ID-JAG) 対応

アクセス失効

• 失効は IdP 側の一箇所で行います。従業員のアクセスを取り消すと、すべての MCP クライアントに対して即時に反映されます。クライアントごと・サーバーごとの個別失効操作は不要です。
• ただし失効が及ぶ範囲には限界があります。

• したがって「IdP での失効=全システムからの即時遮断」ではなく、「新規のアクセストークン発行の即時停止」と理解するのが正確です。
• 発行済みトークンまで含めた即時失効を実現したい場合、MCP サーバー (Resource Server) 側でトークンイントロスペクションや短い有効期限運用を組み合わせる必要がありますが、この点の具体的な実装手順は公式ドキュメントに記載がありません。

監査ログ

• IdP は「MCP サーバーへのすべてのアクセスに対する監査可能な認可証跡」を提供します。組織のコンプライアンス要件はこの証跡で満たすことを想定しています。
• IdP が監査できる範囲は、ID-JAG 発行とアクセストークン発行という「認可の意思決定プロセス」に限られます。
• IdP の可視性は「アクセストークン発行のプロセスに限定され、実際の MCP トラフィックには及ばない」と仕様に明記されています。

• 「誰が MCP サーバーにアクセスできる状態か」は IdP 側で監査できますが、「実際に何のツールを呼び出したか」はサーバー側の監査ログ実装に委ねられます。両方が必要な場合は、サーバー側の監査ログ整備を別途行う必要があります。

トークンライフタイム管理

• ID-JAG とアクセストークンは別々のライフタイムを持ちます。

• 両方とも仕様本文が定める必須値ではなく例示ですが、ID-JAG は極めて短命、アクセストークンはそれより長寿命という設計思想が読み取れます。
• アクセストークンの更新について、仕様は MCP Authorization Server 向けの通常の OAuth refresh_token グラントを規定していません。クライアントは保存しておいた Identity Assertion (ID Token / SAML assertion、IdP が対応すれば refresh_token を subject_token にする経路も可) から IdP に再度 ID-JAG を要求するか、有効な ID-JAG が残っていればそれを再提示して、MCP Authorization Server のアクセストークンと再交換します。
• クライアントは IdP が発行するトークンのスコープ制約を尊重し、スコープエラーを適切にハンドリングする実装が求められます。

運用モニタリング (実装案)

継続的に監視すべき指標は仕様・公式ドキュメントに定義がありません (公式未明示)。EMA のフロー構造から導ける監視候補は以下です。

ベストプラクティス

権限設計 (最小権限スコープ・サーバー単位のポリシー粒度)

• IdP が制御できる粒度は、MCP サーバー側が定義した OAuth スコープの粒度に依存します。サーバーが粗いスコープしか公開しない場合、IdP 側でも粗いポリシーしか組めません。
• 導入前に、MCP サーバー側で「読み取り/書き込み」「リソース種別ごと」などの細粒度スコープを設計しておくことを推奨します。
• IdP のポリシーは MCP サーバーごとに個別設定するため、サーバー単位でポリシーの責任範囲を明確にします。

個人アカウント混線の防止

• EMA が前提とする配布方式は、企業 IdP 経由の SSO 一本化です。個々のユーザーが個人アカウントで MCP サーバーを直接認可するフローと共存すると、IdP のポリシーを迂回するアクセス経路が残ります。
• MCP サーバー (Resource Server) 側でのアカウント連携は、ID-JAG の sub クレームを主キーとして扱い、既存アカウントとの突合には補助的に email クレームを使う設計が仕様で推奨されています。
• sub を安定識別子として優先するのは、email が変更され得る一方、sub は IdP 内で不変であることを踏まえた設計です。

EMA が解決しない範囲

セキュリティ考慮事項

IETF draft (draft-ietf-oauth-identity-assertion-authz-grant) の Security Considerations 章、および MCP 仕様の Security Considerations 章を正としてまとめます。

トラブルシューティング

XAA はベータ段階のため、既知の制約が明示されています。以下の表で「(Auth0 XAA beta)」と付記した制約の出典は Auth0 (Customer Identity Cloud) の XAA beta ドキュメントです。Okta Workforce Identity Cloud (Claude beta ガイドの対象) 側のドキュメントには同じ制約の記載がなく、Workforce 側への適用有無は公式未確認です。それ以外の項目は仕様上「公式未明示」です。

まとめ

EMA は、MCP の認可を「ユーザーがサーバーごとに個別 OAuth する」方式から「企業 IdP が ID-JAG を発行して一括制御する」方式へ切り替える拡張です。新しいトークンや信頼モデルを発明せず、ID-JAG (RFC 8693 の Token Exchange と RFC 7523 の JWT Bearer Grant) と Identity Chaining という既存要素を MCP に当てはめたプロファイルであり、統制・監査・失効を IdP に集約できる一方、発行済みアクセストークンの即時失効やサーバー内の fine-grained 認可は依然としてサーバー側の責務として残ります。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

概要・仕様

• Enterprise-Managed Authorization (modelcontextprotocol.io)
• Enterprise-Managed Authorization: Zero-touch OAuth for MCP (公式ブログ, 2026-06-18)
• enterprise-managed-authorization.mdx (仕様原文, GitHub)
• SEP-990: Enable enterprise IdP policy controls during MCP OAuth flows
• ext-auth リポジトリ解説 (deepwiki)
• Extension Support Matrix (modelcontextprotocol.io)
• Centrally manage authorization for MCP connectors (Claude by Anthropic)

構造・基本認可仕様

• Authorization | Model Context Protocol Specification (2025-11-25)
• Cross App Access: Build Secure Agent-to-App Connections (Okta Developer Blog)
• How We Brought Enterprise-Managed Authorization to Rovo MCP with XAA and ID-JAG (Atlassian)

データ (IETF draft)

• draft-ietf-oauth-identity-assertion-authz-grant (IETF Datatracker)
• draft-ietf-oauth-identity-assertion-authz-grant-04 (HTML)

構築方法・利用方法

• Make Secure App-to-App Connections Using Cross App Access (Okta Developer)
• Develop a XAA-Enabled Resource Application and Test with Okta (Okta Developer)
• Introducing xaa.dev: A Playground for Cross App Access (Okta Developer)
• Claude Enterprise-managed auth with Okta Cross App Access (XAA) Beta Participation Guide (Okta Support)
• Set up AI agent token exchange (Okta Developer Docs)
• okta-samples/okta-xaa-dev-mcp-client-example (GitHub)
• Visual Studio Code 1.123 Release Notes

運用・ベストプラクティス

• Cross App Access: Securing AI agent and app-to-app connections (Okta Identity 101)
• Cross App Access (XAA): The enterprise way to govern AI app integrations (WorkOS)
• Cross App Access (XAA) beta (Auth0 Docs、beta 制約の出典)