MCP が企業向け統一認可を発表：1回のログインで全コネクタが自動で利用可能に

2026-07-13

·Toolin 編集部

Model Context Protocol が Enterprise-Managed Authorization 拡張を発表。企業は Okta などの IdP で MCP Server へのアクセスを一元管理でき、ユーザーは設定ゼロで初回ログイン時に接続完了します。

2026-07-13· Toolin 編集部

MCP が企業向け統一認可を発表：1回のログインで全コネクタが自動で利用可能に

EMA が解決するもの中核メカニズム：ID-JAG すでにサポートしているのは誰か導入方法企業ユーザーの場合 MCP Server 開発者の場合いつ EMA を使うべきか

AIチュートリアル

企業で MCP（Model Context Protocol）を推進しているなら、最も苦痛なのは Server の接続ではなく認可かもしれません。従業員ごとに各 MCP Server に対して個別に OAuth を進めなければならず、セキュリティチームは統一的に監査できず、個人アカウントと企業アカウントも混ざりがちです。MCP 公式が発表したばかりの Enterprise-Managed Authorization（EMA）拡張はまさにこの問題を解決するためのもので、すでに stable になっており、Anthropic、Microsoft、Okta が利用しています。

EMA が解決するもの

標準の MCP 認可は user-scoped で、各ユーザーが各 Server に対して個別に認可します。これは企業シーンでは3つの致命的な弱点があります：

各人が各 Server を認可する必要がある：入職のたびにサービスを1つずつ手動で接続しなければならない
セキュリティチームが統制できない：アクセス権限は各ユーザーがその時何を認可したかに依存し、中央管理と監査がない
業務アカウントと個人アカウントの混在：企業 identity を強制できず、ユーザーが個人アカウントを業務ツールに接続できてしまう

EMA は組織の IdP（identity provider）を MCP Server アクセスの権威ある意思決定者にします。管理者がポリシーを1回定義すれば、ユーザーは既存の identity で MCP host にログインし、IdP がグループ、役割、条件付きアクセスルールに基づいてアクセスを許可または拒否します。

中核メカニズム：ID-JAG

EMA の基盤となるフローは per-server consent screen に依存しません：

ユーザーが SSO ログインすると、クライアントは IdP から Identity Assertion JWT Authorization Grant（ID-JAG） を取得する
クライアントは ID-JAG を使って MCP Server の認可サーバーから access token と交換する
ユーザーが per-server consent ページへリダイレクトされることは決してない

これにより3つの性質がもたらされます：

1回の認可で everywhere に継承：管理者が組織に対して1つの Server を有効化すれば、ユーザーは自動的に取得し、その既存のグループ/役割の範囲に限定される
集中ポリシーと監査：アクセスの意思決定はすべて IdP の管理コンソールにあり、全コネクタを横断する1本の監査証跡
個人/企業アカウント混用の解消：対話的なアカウント選択ステップがなくなり、個人と企業アカウントの間でデータが誤って流れるリスクが下がる

すでにサポートしているのは誰か

EMA の最初のエコシステムは3者で構成されます：

identity provider（IdP）

Okta が最初に対応した IdP。組織は Okta の Cross App Access（XAA）を通じて、対応する Server へ MCP アクセスを provision できる

クライアント

Anthropic は共有 MCP 層で EMA を実装済み。管理者は Claude、Claude Code、Cowork を横断してユーザーに MCP Server を認可できる
Visual Studio Code は IDE 内で直接 EMA をサポート済み

Server 側

Asana、Atlassian、Canva、Figma、Granola、Linear、Supabase が EMA をサポート済み
Slack などは接続作業中

導入方法

企業ユーザーの場合

IdP が対応しているか確認（現時点で Okta、XAA プロトコル経由）
IdP 管理コンソールで組織に対象の MCP Server を有効化し、グループ/役割でスコープを限定
ユーザーが初めて Claude / Claude Code / VS Code にログインした時点で、認可済みのコネクタを自動的に取得し、1つずつ OAuth を進める必要がない

MCP Server 開発者の場合

公式仕様を参照して EMA を実装します：

仕様ドキュメント：Enterprise-Managed Authorization に client、server、authorization server の各当事者が実装すべきフローが詳述されている
ソースコードと spec：ext-auth リポジトリに最新 spec とサポート資料が含まれる
コミュニティ：EMA Interest Group に参加して互換性や spec の反復を議論

いつ EMA を使うべきか

シーン	EMA を使うか
企業全体で統一的に MCP を推進	はい、onboarding の摩擦を大幅に低減
集中的なセキュリティ監査が必要	はい、IdP で1本の監査証跡
個人開発者がローカルでいくつかの Server に接続	いいえ、標準 OAuth で十分
企業 identity を強制してデータ漏洩を防ぐ	はい、対話的なアカウント選択を除去

EMA は標準の MCP 認可を置き換えるものではなく、拡張として、企業シーンに「ゼロタッチ」の選択肢を与えます。中小チームや個人ユーザーにとって、従来の per-user OAuth フローは影響を受けません。

一次ソース：

すべての記事