MCP EMAとは？Enterprise-Managed AuthorizationのIdP・SSO・ID-JAG設計

先に結論：EMAはMCPの認証を組織のIdPへ寄せる拡張

MCPのEnterprise-Managed Authorization（EMA）は、各ユーザーが各MCP serverへ個別にauthorizeする代わりに、組織のIdentity Provider（IdP）をアクセス判断の中心に置く拡張です。会社のSSOでユーザーがMCP clientへログインし、IdPがgroup、role、conditional accessなどのポリシーに基づいて接続可否を決めます。MCP公式ブログでは2026-06-18にEMAがstableになったと発表されていますが、実際に使えるclient・server・IdPの組み合わせは個別に確認が必要です。

EMAが解決する企業MCPの4つの負担

• 新しい社員が多数のMCP serverを一つずつauthorizeする負担
• security teamがユーザーごとの許可を追いかけ、統一したpolicyを適用しにくい問題
• 入社・異動・退職時に、各client・各serverのaccessを個別に変更する負担
• 仕事用と個人用のaccountが混ざり、意図しないdata経路ができるリスク

EMAでは、組織の管理者が承認済みMCP serverとアクセスpolicyをIdP側で管理します。ユーザーは会社のidentityでログインし、IdPの判断により接続できるserverだけが利用可能になります。個人開発者が単一serverを自分だけで使う場合は、EMAの導入コストがメリットを上回る可能性があります。

通常OAuth・Client Credentials・EMAの違い

EMAを導入しても、MCP server側のtool権限、scope、data classification、監査はなくなりません。IdPが接続可否を決める層と、MCP Authorization Serverがtokenとresourceを検証する層を分けて設計します。

EMAの登場人物と責務

基本フロー：SSOからID-JAG、access tokenへ

• ユーザーがenterprise IdPを使ってMCP clientへSSOする
• clientがIdentity Assertion（OpenID ID TokenまたはSAML assertion）を保持する
• MCP serverがenterprise-managed authを要求したら、clientがIdPのauthorization endpointへID-JAGを要求する
• clientがID-JAGをMCP Authorization Serverへ渡し、MCP server向けaccess tokenへ交換する
• clientがscopeとresourceを確認し、MCP serverへtool requestを送る
• IdPのgroup、role、conditional accessにより、許可されないserverのtokenは発行されない

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

clientはper-request capabilitiesでEMA対応を宣言します。宣言できることは、IdP policyが正しいことやMCP serverへの権限があることを意味しません。client、server、Authorization Serverが同じextension identifierを扱い、必要なscopeとfallbackを確認します。

IdP側で設計するpolicy

EMAの便利さは、ユーザーが一度ログインすれば多くのserverへ接続できることより、管理者が承認・変更・失効を組織単位で扱えることにあります。承認済みserverのregistry、group・roleの棚卸し、offboardingのrevoke、監査ログを運用に組み込みます。

ID-JAGとMCP access tokenを同じものにしない

ID-JAGはenterprise IdPからMCP Authorization Serverへ渡すためのIdentity Assertion JWT Authorization Grantです。MCP serverへ最終的に送るaccess tokenとは役割が違います。Authorization ServerはID-JAGのsignature、audience、issuer、expiration、scope・resource情報を検証し、MCP server向けtokenを発行します。受け取ったassertionやtokenを別のserverへ転送しない境界を保ちます。

scopeはEMAでも狭く、組織policyとtool権限を合わせる

• IdPのgroupやroleが許可されても、MCP serverのtool scopeを自動で全許可にしない
• organization、project、environment、read/write/deleteを別のscopeまたはpolicyとして表にする
• standard MCP OAuthと異なるscope制限が出る可能性をclient側で扱う
• scope不足をユーザーへ再同意させるのではなく、IdP policyと管理者承認の不足として切り分ける
• access tokenがあることと、全toolを安全に実行できることを分ける

中央失効とアカウント混同を検証する

EMAの中心的な効果は、ユーザーの退職や権限変更をIdPで処理し、MCP serverへのaccessを中央でrevokeできることです。管理者がgroupを外したあと、既存session、refresh、cache、client表示、server側token検証がどのタイミングで拒否に変わるかをテストします。アカウント連携では、公式ガイドがsubjectを主な安定識別子とし、既存アカウントの照合にemailを補助的に使う考え方を示しています。email文字列だけを恒久IDにしない設計が安全です。

client・server・Authorization Serverの導入チェック

• clientがEMA extensionをcapabilityで宣言し、企業IdPのSSOとIdentity Assertionを扱える
• serverがauthorization metadataでenterprise-managed flowを要求する条件を示す
• Authorization ServerがID-JAGのsignature、audience、issuer、expirationを検証する
• IdP claimsをMCPのscope、resource、accountへ安全にmappingする
• 組織管理者がper-userではなくorganization-level settingsでserverとpolicyを管理できる
• scope不足、未承認server、IdP失敗、revoke、account linkingをテストできる
• client matrixで、使うclient・server・IdPの対応状況とversionを確認する

EMAを導入しない方がよいケース

client supportは『EMAがstable』だけで判断しない

EMAの公式拡張ページでは、client supportはclientごとに異なり、extensionはopt-inで自動有効ではないと説明されています。公式ブログのstable発表は拡張の状態を示すもので、あなたのCodex、Claude Code、MCP host、server、IdPの組み合わせがすぐ利用できるという意味ではありません。support matrix、clientの管理者設定、serverのauthorization metadataを同じ日付で確認します。

企業MCP導入前の最小チェックリスト

• EMAが必要な組織課題（server数、onboarding、offboarding、監査、account混同）を言語化した
• 承認済みMCP serverのregistryと、IdPで管理するgroup・role・conditional accessを作った
• client・server・Authorization ServerがEMAの同じextension identifierを扱うと確認した
• SSO、Identity Assertion、ID-JAG、MCP access tokenの保存場所と有効期限を分けた
• ID-JAGのsignature、audience、issuer、expiration、claims mappingをテストした
• MCP tool scopeと組織policyをread/write/delete、environment、project単位で最小化した
• group変更・offboarding・IdP障害・scope不足・未承認serverをテストした
• client support matrixと管理者設定の確認日・versionを記録した

まとめ：zero-touchの前に、central policyとrevokeを作る

MCP EMAは、SSOで接続を簡単にするだけの機能ではなく、組織のIdPを承認済みserver、group、role、conditional access、監査、中央失効の中心へ置く拡張です。ID-JAGとMCP access tokenを分け、client・server・Authorization Server・管理者の責務を確認し、最初はread-onlyと小さなserver registryから始めます。公式ブログでstableと案内されていても、client・server・IdPの実装対応は別に検証してください。