MCP向けゼロタッチOAuth

2026年6月19日原文(blog.modelcontextprotocol.io)

概要

Enterprise-Managed Authorization（EMA）拡張機能 が安定版としてリリース
企業がMCPサーバーの認可を一元管理 でき、ユーザーはシングルサインオンが可能
Anthropic、Microsoft、OktaなどがEMAを採用
従来の認可モデルの課題 を解決し、セキュリティと運用効率を向上
さらなる採用促進とコミュニティ参加を呼びかけ

Enterprise-Managed Authorization（EMA）拡張機能の安定版リリース

EMA拡張機能 が安定版として公開、企業向けMCPサーバー認可の一元管理を実現
Anthropic、Microsoft、Okta など主要企業が導入を開始
従来のMCP認可モデル では、各ユーザーがサーバーごとに個別認可が必要、運用コスト増大
セキュリティチームによる統一ポリシー管理 が困難、監査トレイルの欠如
個人アカウントと業務アカウントの混在 によるリスク発生

EMA拡張機能の利点と仕組み

組織のIdP（Identity Provider） がMCPサーバーアクセスを一元管理
エンドユーザーはシングルサインオン で全MCPサーバーにアクセス可能、初回ログイン時に自動接続
管理者が一度ポリシーを設定 すれば、ユーザーは既存の権限範囲で即時利用可能
ID-JAG（Identity Assertion JWT Authorization Grant） を活用し、IdPで認証・認可を完結
ユーザーは個別の同意画面を経由せず、認可が自動継承される
中央集約型のポリシー・監査 が可能、アクセス管理の透明性向上
個人・業務アカウントの混在防止 が容易に

主要な導入事例

Okta ：最初の対応IdP、Cross App Access（XAA）経由でMCPアクセスを管理
Anthropic ：Claude、Claude Code、CoworkでEMAを実装、管理者が一括認可
Visual Studio Code ：IDE内でEMAサポートを追加
サーバー側 ：Asana、Atlassian、Canva、Figma、Granola、Linear、SupabaseがEMA対応、Slackも導入中

EMAの今後とコミュニティ参加

さらなるIdP、クライアント、サーバーの採用 を推進
MCPのセキュリティ強化 と運用効率の大幅な向上を目指す
拡張仕様や導入要件 はEnterprise-Managed Authorization公式ページにて公開
ext-authリポジトリ やドラフト仕様書で最新情報を提供
EMA Interest Group 参加によるフィードバックや議論を歓迎

関係者のコメント・謝辞

Okta ：セキュリティとユーザー体験の両立、中央集約型ガバナンスの実現
Figma ：エンタープライズ規模でのMCP導入を安全かつ迅速に
Linear ：シングルサインオンによる自動コネクタ設定の利便性
MCPコミュニティ全体 ：SEP-990著者、ext-authリポジトリ管理者、初期導入企業への感謝

EMA導入を検討する企業へのアクション

公式ドキュメントや仕様書の確認 による理解促進
自社プロダクトへのEMA対応検討、実装計画策定
コミュニティへの参加、意見交換や実装事例の共有

Hackerたちの意見

これが普通のOAuthよりもどんなメリットがあるのか、よくわからないな。認証フローの比較例が欲しい。

└

普通のOAuthでは、エンドユーザーがアプリケーションごとにデータを共有することに同意するんだよね。これは、エンドユーザーが自分のデータを持っている消費者向けのケースでは理解できるけど、ビジネスのケースではあまり意味がない。ビジネスがデータの共有やアクセスを管理すべきなのに、エンドユーザーがそれを決めるのはおかしい。例えば、Acmeの社員として、自分のAcmeのGoogle DriveデータをClaudeやChatGPTにリンクするかどうかを決めるべきじゃない。それはIT部門が決めることだよね。Enterprise-Managed OAuth（EMA）やCross App Access（XAA）は、IT管理者が中央で制御する共有モデルをOAuthフレームワークに組み込んで、既存のエコシステムと連携できるようにするんだ。データ共有の同意管理を社員からIT管理者に移すことで、UXも良くなるし、社員がアカウントをリンクするためにたくさんのOAuthフローを通過する必要がなくなる。IT管理者がすでに共有コントロールを設定しているから、すべてがスムーズに動くはず。新しい会社に入社した初日に、SlackがすでにZoomやDrive、カレンダーにリンクされている感じだね。

└

利点は、ユーザーがどのアプリに情報を共有するかを承認する必要がないことだね。アクセスを委任する決定はIdPのポリシーレベルで行われるから。ユーザーはどのアプリやサービスが情報を共有するために承認されたかを知らないかもしれない。これって、逆に利点なのかな？ ;-)

OktaやMicrosoft、Figma、Linearなどの皆さん、本当におめでとう！MCPに否定的な人たちも心配しないで、あなたたちにも何かあるから :) これはID-JAGという新しいトークンフォーマットによって実現されているんだ - https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... - で、MCP専用ではないよ。ID-JAGは、同じSSOプロバイダーを使っているアプリケーション間でデータを安全に共有するために使えるんだ。

└

こういう会社のせいでソフトウェアと生活の質が最悪になってる。ほんと、彼らにはおめでとうって感じだね。

「MCPは死んだ、スキルは永遠だ」といういつもの議論に深入りする前に、MCPがスキルやCLIに対して提供する本当の価値は、認証フローをエージェントのコンテキストウィンドウの外に隔離できることなんだ。これはセキュリティの観点からも重要だし、AIツールを導入する一般の人や大企業にとっても、使いやすい体験になる。コンテキストの膨張やツールコールの冗長性についての不満はよく聞くけど、この認証を扱う構造には本当に価値があると思う。理想的なMCPの形は、APIのための認証ゲートウェイだけかもしれない。それでも十分に勝利だよ。

└

認証をコンテキストウィンドウの外に置くのはいいと思う。でも、MCPの本当の価値は、APIの上にセマンティックレイヤーを追加することなんだ。スキルはクライアントサイドで、サーバーの能力を知らない。MCPはサーバーがそのAPIを自然言語で説明できるようにするから、サーバーやAPI、ドメインについての知識がないクライアントでも賢く使えるんだ。前はMCPがバカだと思ってたけど、大きなMCPサーバーに書いたことがあって、CAD用と音楽用のものがあったけど、今では完全に考えが変わったよ。

└

MCPがスキルやCLIに対して提供する本当に価値のある機能は、MCPとスキルは二項対立ではないってことだね。単に異なるツールなんだ。それぞれ異なる要件に応じて、どちらが良いかは変わる。ナイフとノコギリ、どっちがいいかって話だよ。

└

MCPは素晴らしい監査トレイルも提供してくれるし、責任の分離も可能にするんだ。つまり、6つのクライアントにわたって6つのリニアアカウントを認証して、どれを使うかを決めることができるんだ。

皆さん、こんにちは！私はAnthropicの一員で、OktaやいくつかのMCPパートナーと協力してこれを実現しました。Claudeでこの形ができることにすごくワクワクしてるし（もちろんMCP仕様も含めて、EMAは今や安定した拡張になってる）、他のアイデンティティプロバイダーやクライアントへの導入も進めていきたいと思ってます。フィードバックがあれば、ぜひここに書いてください！皆さんの体験や、どうやってもっと良くできるかを聞くのが楽しみです。

└

素晴らしいニュースだね。Microsoft Entra（Azure AD）チームとの連携はあるの？これがすぐに期待できるのか、もう少しかかるのか知りたいな。

└

いい仕事だね、これをやってくれてありがとう。ちょっと確認したいんだけど、まだ利用可能じゃないよね？まだSEPの段階？

Hacker Newsで議論の続きを見る

ハクソク