MCP向けZero-Touch OAuth
(blog.modelcontextprotocol.io)- Enterprise-Managed Authorization(EMA) 拡張が安定版となり、企業はMCPサーバー権限を一元管理でき、ユーザーは一度ログインするだけで許可されたサーバーにアクセスできるようになった
- 従来方式はユーザーごと・サーバーごとの個別OAuth承認に依存しており、オンボーディング、セキュリティポリシー適用、監査追跡、業務用・個人用アカウントの分離を難しくしていた
- EMAは組織のIdPを権限決定の主体とし、管理者がポリシーを一度定義すれば、ユーザーは既存の組織アカウントで必要なMCP接続を継承できる
- SSO中に発行されたID-JAGをMCPサーバーの認可サーバーでアクセストークンに交換するため、ユーザーはサーバーごとの同意画面にリダイレクトされない
- Okta、Anthropic、Visual Studio Codeに加え、Asana・Atlassian・Canva・Figma・Granola・Linear・Supabaseが初期サポートに含まれ、Slackもサポートを追加中である
EMAの安定化と企業展開の目標
- Enterprise-Managed Authorization(EMA) extension がstable状態になった
- 企業環境でMCPサーバー接続を管理する際、繰り返しの承認と同意プロンプトが大きな不便とされており、EMAはこの問題を減らすための拡張である
- 組織は信頼するIDプロバイダー(IdP) を通じてMCPサーバーアクセスを中央制御できる
- エンドユーザーは既存の組織アカウントでログインした後、許可されたMCPサーバーに接続し、サーバーごとのOAuth同意や一回限りの設定負担が減る
ユーザー別認証モデルの限界
- 標準のMCP権限モデルはユーザースコープ(user-scoped) と従来の対話型認証の慣例に合わせて設計されている
- 個人が自分のデータへのアクセス先を直接決める消費者シナリオには適していても、企業展開ではうまくスケールしない
- 企業環境では特に3つの問題が大きくなる
- 従業員ごとにサーバーを個別承認しなければならず、オンボーディング時にサービスごとの手動接続が必要になる
- セキュリティチームは中央制御や監査追跡なしに、各ユーザーが承認したアクセスに依存することになる
- 会社アカウントを強制しにくく、ユーザーが個人アカウントを業務ツールに接続できてしまう
- このような摩擦はMCP導入を遅らせ、脆弱な回避実装を生む可能性を高める
- 共有認証状態を保存する汎用標準がなければ、実装者ごとに別個の解決策を作ることになり、データやツールがあってもユーザー別権限のコストのため大半が無効のままになりうる
一度承認すればどこでも継承
- Enterprise-Managed Authorization は、組織のIdPをMCPサーバーアクセスの権限決定主体にする
- 管理者はポリシーを一度定義し、ユーザーは既存の組織IDでMCPホストに認証する
- IdPはグループメンバーシップ、ロール、条件付きアクセスルールに応じてアクセスを許可または拒否できる
- 内部フローは次のとおり
- クライアントがSSO中にIdPから Identity Assertion JWT Authorization Grant(ID-JAG) を取得する
- クライアントがこれをMCPサーバーの認可サーバーに送り、アクセストークンと交換する
- ユーザーはサーバーごとの同意画面を経由しない
- この構造がもたらす効果は3つある
- 管理者が組織内でサーバーを有効化すると、ユーザーは既存のグループとロールの範囲内で自動的にアクセスできる
- アクセス決定はIdP管理コンソールに残り、すべてのコネクターに対して単一の監査可能な記録を提供する
- 対話型のアカウント選択ステップをなくすことで、個人アカウントと企業アカウントの間のデータフロー混在を減らしやすくなる
- MCPの企業利用における目標は、ユーザーがログインしたとき追加ステップなしで、許可されたツールとデータにクライアントが接続される状態である
初期対応製品とエコシステム
- 今回のリリースでは、IDプロバイダー、クライアント、サーバーの3グループが実装に参加している
-
IDプロバイダー
- Oktaが最初の対応IDプロバイダーである
- Oktaを利用する組織は Okta’s Cross App Access(XAA) を通じて、対応クライアントとサーバーにMCPアクセスをプロビジョニングできる
-
クライアント
- Anthropic はClaudeの共有MCPレイヤーにEMAを実装した
- 管理者はClaude、Claude Code、Cowork全体でユーザー向けMCPサーバーを承認できる
- Visual Studio Code もIDE内にEMAサポートを追加した
-
サーバー
- Asana、Atlassian、Canva、Figma、Granola、Linear、SupabaseがEMAをサポートしている
- Slackおよびその他のサーバーもサポートを追加中である
- OktaのAaron Pareckiは、Cross App AccessプロトコルをMCPのEMA拡張に組み込むことで、identityを中央ガバナンスプレーンにし、セキュリティチームにはコンプライアンス制御を、ユーザーにはシームレスな体験を提供すると述べた
- FigmaのDevdatta Akhaweは、MCP導入が増える中でXAAが企業のMCP展開を安全にスケールさせやすくすると述べた
- LinearのTom Moorは、一度ログインすればすべてのMCPコネクターが自動設定される体験に言及した
ドキュメントと参加チャネル
- クライアント、サーバー、identity platformは拡張仕様を確認し、製品に新標準サポートを追加できる
- Enterprise-Managed Authorization page では、クライアント、サーバー、認可サーバー向けのフロー要件が文書化されている
- ext-auth repository と draft specification で、EMAの最新変更とサポート資料を確認できる
- 拡張の議論、互換性レポート、反復改善には EMA Interest Group が使われている
- EMAはMCPコミュニティの作業であり、SEP-990の作成者、ext-authリポジトリのメンテナー、初期実装をテストし仕様を前進させたidentityおよびMCP providerが貢献している
1件のコメント
Hacker Newsの意見
よくある「MCPは終わった、未来はSkillsだ」という議論に行く前に、MCPがskills/CLIより実際に価値を持つ点は、認証フローをエージェントのコンテキストウィンドウの外に、場合によってはハーネスの外にまで分離できることにある
これはセキュリティの観点でも当然重要だし、一般ユーザーや大企業がAIツールを導入する際にも、はるかに導入しやすいユーザー体験になる
コンテキスト肥大化やツール呼び出しの重複への不満は理解できるが、認証をこのように扱う構造には明確な価値がある
理想的なMCPは、API手前の認証ゲートウェイであるだけでも十分にメリットがありうる
現在のskills配布のベストは「このファイルをコピーしてここに入れる」「このリポジトリをチェックアウトしてシンボリックリンクを追加する」「スラッシュコマンドでインストールする」程度に見える
シンプルではあるが、新しいMCPサーバーを従業員に配布するこの拡張方式ほど簡単ではない
たとえば6社の顧客のLinearアカウント6つを認証しておき、どのアカウントを使うかを決定論的かつ監査可能な形で選ぶ、といった責任分離も可能だ
両者は単に異なるツールであり、要件によってどちらが向いている場合もあれば、そうでない場合もある
ナイフとノコギリのどちらが優れているかを問うようなものだ
この話題が出るたびに、エンジニアたちはClaude CodeだけをAIエージェントの唯一のアプリであるかのように扱うが、コーディング以外にも多くの業種に数え切れないユースケースがある
ハーネスはローカルマシンではなく、クラウド上の隔離され制限されたコンテナで動作し、任意コード実行が絶対に許されない環境かもしれない
それでも顧客が既存ツールをエージェントに接続したい場合、MCPは認証を内蔵したコネクタを提供するので最適であり、skillsはこの領域には当てはまらない
一般ユーザーはClaudeディレクトリを探してskillファイルを貼り付けたりはしない
「Connections」のほうが理解しやすく、MCPを貼り付けるかマーケットプレイスで探すほうが簡単だ
場所とレビューにエージェントがアクセスできることが実際に有用かどうかは、まだ未確定だ
Okta、Anthropic、Microsoft、Figma、Linearなどでこの取り組みを作った人たちに大きな祝福を送りたい
MCP懐疑派にとっても使い道がある
これはID-JAGという新しいトークン形式で動作し、https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...にある
MCP専用ではまったくなく、同じSSOプロバイダーを使うアプリケーション同士でデータを安全に共有する必要があるなら、どこでもID-JAGを使える
現在実装中のMCPサーバーにMicrosoft Entra ID認証を付けようとしているのですが、正直自分がバカになったような気分です
WWW-AuthenticateヘッダーでクライアントにリソースメタデータURLを知らせることができ、これによって認証サーバーであるMicrosoft Entraとアプリ登録のスコープも指定できますしかし
client_idは指定できず、それは各クライアント、つまりエージェントが勝手に作るという話ですMicrosoft Entra の
.../authorizeURL でログインを開始するには、Entra のアプリ登録と一致する既知のclient_idが必要ですが、クライアントが任意に作った値が Entra に合うはずがありません理論上は動的クライアント登録をサポートできますが、Microsoft Entra は当然ながらサポートしていません
結局、Microsoft Entra の前段に独自の動的クライアント登録 shimを作って、全員に同じ静的
client_idを返す方法しか見当たりませんこのプロトコルが実際のエンタープライズ環境で回避策なしに動くのが正しいのか、自分が何か明らかな点を見落としている気がします
Entra ID は動的クライアント登録をサポートしておらず、このエコシステムの現状はまだ良くありません
通常、MCP OAuth は事前登録された従来型のクライアントで処理しますが、実際には多くの MCP クライアントが動的クライアント登録がある前提で、
client_idを指定するオプションを提供していませんただし一部のクライアントはこれをサポートしており、宣伝も兼ねて言えば、私たちのツール Erato も対応しています: https://erato.chat/docs
エンタープライズで導入される一般的なソリューションも、通常は Web UI を通じて MCP アクセスを一元化するため、これをサポートしています
別の代替案としては MCP ゲートウェイがあり、ゲートウェイとサービスの間では事前登録 OAuth を使い、ゲートウェイとクライアントの間では動的クライアント登録を許可できます
client_idのせいで同じ問題に直面し、セキュリティ上動的クライアント登録を有効にしたくありませんでした最終的にはアプリが OAuth フローをプロキシし、ハードコードされた
client_idを注入するようにしましたMCP クライアントには動的クライアント登録をサポートしているように見せかけつつ、内部では MCP 用の独立した
client_idを通常どおり使う構成です例はこちらです: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
そのうえで OpenID でクライアント登録を処理し、JWT を作成する認証ブローカーアプリケーションを作りました
その結果、従業員の部署やその他の基準に基づいて、ツールを利用できるかどうかや権限を決定できるようになりました
結局のところ動的クライアント登録は必要です
DCR のより新しく優れた兄弟である CIMD も検討中で活発に議論されていますが、まだ提供されていません: https://github.com/FusionAuth/fusionauth-issues/issues/3230
提案されていたプロキシの代替としては、開発者ポータルなどで MCP クライアントごとに PKCE を有効にした新しい Entra
client_idを作成し、ユーザーにその値をクライアントへ設定してもらう方法がありますそのための CLI コマンドはここで見つけましたし、API もあるはずです: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
Claude Code の設定は https://code.claude.com/docs/en/mcp、ChatGPT の設定は https://developers.openai.com/api/docs/guides/developer-mode にあります
事前クライアント登録は開発者にとって最適ではないとしても受け入れ可能であり、仕様でも第一級の方式として扱われています: https://modelcontextprotocol.io/specification/2025-11-25/bas...
主なユーザーが社内従業員で、MCP サーバーへアクセスするための設定手順に従えるのであれば、この方法でも機能します
しかし対象が開発者ではない幅広い公開統合であれば、確かに受け入れがたいものであり、まさにそこに MCP の大きな強みと機会があります
AnthropicでOktaおよび複数のMCPパートナーとともにこれを作った一人です
Claudeでこの形が定着しつつあるのはとても楽しみですし、MCP仕様でもEMAが安定拡張になったので、他のIDプロバイダーやクライアントにも採用を広げたいです
フィードバックがあればここに残してもらえるとうれしいですし、実際の利用経験や改善方法はいつでも聞きたいです
しばらくMCPを追っていませんでしたが、これは組織でMCPをより安全にし、動的クライアント登録の弱点を解決するのにかなりうまく合っているように見えます
これでクライアントと承認済みリダイレクトURIをIDプロバイダーと組織が直接設定できるようになるので、混同代理攻撃やフィッシングのようなDCRベースの攻撃をより広く緩和できます
また、IDプロバイダーや組織がDCRをサポートしていない場合にMCPサーバーが実装しなければならなかった認可ロジックも減るため、大きな利点です
欠点は、コンシューマー用途では依然としてDCRが必要そうに見える点です
GitHub、GitLab、Googleのようなコンシューマー向けOAuthプロバイダーが静的なMCPクライアント/サーバー登録をサポートし、クライアントが静的な
client_idを組み込み、ユーザーがそのIDプロバイダーでログインして接続を直接管理できるようになれば、解決できるかもしれません全体として、XAA/EMAはセキュリティと使いやすさの両面でDCRよりはるかに優れているように見えます
懸念点もDCRよりずっと対処しやすく、セキュリティへの影響も小さいです。攻撃者が自分のクライアントを登録できず、MCPサーバー開発者がはまりがちな落とし穴も減るからです
何らかの一時セッションや帯域外トークンストアがあるとよいです
ユースケースとしては、営業プロセスで買い手と売り手が多くの情報をやり取りし分析する必要があり、その分析がますますエージェント的になっているというものです
MCPの問題は、初期設定の摩擦が、ユーザーが自分でログインして必要な情報を取得するよりはるかに大きいことです
MCPは定期的で頻繁なやり取りには向いていますが、素早い一回限りのセッションには問題が多いです
Claudeで「X、Y、Zからドキュメントを取ってきて」と言うと、ClaudeがそのWebサイトにアクセスし、サイトは基本的な利用情報と、ユーザーがブラウザで開けるログインリンクを返します
ユーザーがブラウザで認証し、コールバックが一意で短命なワンタイムトークンを返し、その後サイトへのリクエストでそれを交換する方式だとよいと思います
そうすれば、ユーザーをすばやく認証しつつ、作業中のセッション状態も維持できます
近いうちに期待してよいのか、それともかなり時間がかかるのか知りたいです
主なユースケースは会社の従業員向けに見えますが、顧客やプレミアム無料ユーザーのような集中管理されていないユーザーにも似た価値があるのか気になります
いまひとつ思いつかなかったので、自分が何を見落としているのか知りたく、関連する回答はここで見た気がします: https://news.ycombinator.com/item?id=48594381
これは本当に素晴らしいです
この数か月、MCP界隈の人たちといくつかのSEPやGoの実験用SDKを一緒に触れる機会に恵まれました
以前は「ただのAPIじゃないか」「また抽象化を一つ増やしただけだ」と言う懐疑派でした
みんなが見落としているのは、MCPの「P」が誤解を生んでいることです
従来のアプリを作るときは、フォーム、UI、リクエスト/レスポンス処理、双方向チャネル、長時間実行タスク、認証などを作らなければなりません
MCPを使えば、この共通レイヤーの80%が処理されるので、MCPはプロトコルであると同時に、実質的にはアプリフレームワークに近いです
統合認証は非常に大きな強化で、今後さらに面白いものが出てくるのが楽しみです
自分が作った仕事が外から見えるのはかなり不思議な気分です
AtlassianでこのフローのRAS側実装を担当しました
CIMDや、よりよいテナンシー対応など、このフローには今後も反復的な改善があるはずです
Anthropic、Okta、Atlassianでこれを届けた人たちは皆素晴らしかったです
Webをサポートして、単に長期クッキーを発行できるようにしてほしいです
OAuthサーバーなしでこれをやるために、OAuthハンドシェイクでクッキーを通すよう仕様をハックしました
こういうことを許さないのは本当にフラストレーションがたまります
クッキーがなければWebページを開き、クッキーが設定されたら閉じて保存すればいいだけです
MCPについて80ページのミニブックまで書きましたが、それでもなお延々とフラストレーションがあります
使いやすさとセキュリティの両方で問題があり、クッキーはブラウザのために作られたものです
MCPサーバーとクライアントは、ブラウザが保証されない環境で動作することが多いです
長期資格情報は非常に大きな責任を伴います
何度か読み返しましたが、確かに有用です
監査とアクセス制御をIDプロバイダー一か所に集約し、必要に応じてトークン交換を担うプロキシAPIゲートウェイのようにIDプロバイダーが振る舞うこともできます
この分野の他のプレイヤーも採用しているアプローチです
個人的には、IDプロバイダーが私の認識しないところで私の権限をクライアントに委任するという点に少し違和感があります
ブラウザ上でユーザーが存在するフローに慣れすぎているからかもしれませんし、だんだんマシン向けのアクセス集中管理へ進化している感じもします
エンタープライズ環境では、アイデンティティは個人より会社に属するので受け入れやすいのかもしれません
しかし、顧客ID側へ統合するのはまったく別の難題であり、IDプロバイダー・クライアント・リソース認可サーバーの間にこうした信頼を築くのはおそらく簡単ではありません
たとえばGitHubにログインしていればSentryにも自動ログインされるような信頼関係を作ればよいのです
今後やるべきことはまだ多いですが、現時点で最も明確なユースケースは、おっしゃる通りエンタープライズです
管理者は、個々の従業員があちこちクリックして任意の資格情報を選ぶようにはしたくありません
C1では、社内でのMCP利用と製品内MCP Gatewayの両方でMCP認証が大きな悩みの種だったので、これが入ってくるのはとても歓迎
今日、C1がEMA IDプロバイダーとして動作するサポートをリリースし、短寿命のスコープ制限付きトークンを発行するようになった
これでLinearや、私たちが使っているほかのMCPにも接続して、繰り返し発生するOAuthフローから抜け出したい
Claudeは組み込みコネクタの一部、少なくともSlackではこうしたことを魔法のようにやっていて、体験はかなり良い
念のため言うと私はC1のVPEで、深掘りしたい人向けにアプローチを文書化してある: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...
これが通常のOAuthに対してどういう利点があるのか、いまひとつよく分からない
認可フローの比較例が必要そう
コンシューマー用途、つまり最終ユーザーが自分のデータを所有している場合には理にかなっている
ただ、多くのビジネス用途では、データを共有しアクセスを制御すべき主体は最終ユーザーではなく会社だ
Acmeの従業員である私が、AcmeのGoogle DriveデータをClaudeやChatGPTに接続するかどうかを決めるべきではなく、それはIT部門が決めるべきだ
Enterprise-Managed OAuth、あるいはCross App Access（XAA）は、IT管理者が中央で制御する共有モデルをOAuthフレームワークの中に持ち込み、既存のエコシステムと連携して動作できるようにする
また、データ共有への同意管理を従業員からIT管理者に移すことで、ユーザー体験上の利点も大きい
従業員はアカウントを接続するために何度もOAuthフローを通る必要がなく、IT管理者がすでに共有制御を設定済みという状態になる
入社初日にSlackがZoom、Drive、Calendarなどにすでに接続されている状況を思い浮かべればよい
アクセス委任の判断がIDプロバイダーポリシーのレベルで下されるからだ
ユーザーは、どのアプリやサービスが自分の情報を共有する許可を得ているのかを永遠に知らないままかもしれない
ちょっと待って、それって本当に利点なの？ ;-)