みなさんこんにちは、バクラク事業部 Platform部 IDチームの @convto です。
最近MCP関連の仕様や議論をウォッチしており、今回はエンタープライズ向けの MCP 認可に関する提案内容などについて紹介したいと思います！
現行の認可仕様
2025-06-18 版の仕様は以下です。
ここには HTTP ベースの認可は OAuth 2.1 準拠でやるよ！ということが書かれています。
大まかな内容としては以下のようになっています。
- MCPサーバーは OAuth 2.1 リソースサーバーとして振る舞う
- [SHOULD] 認可サーバーは Dynamic Client Registration (RFC7591) をサポートする
- OAuth client を動的に登録できる仕様
- 定義を読むと利便性を意識しての推奨サポートのよう
- DCR をサポートしない場合 client_id などを何らかの手段でMCPクライアントに伝えてくれよな(意訳)、と記載されている
- [MUST] MCPサーバーは Protected Resource Metadata (RFC9728) を実装する
- 保護されたリソースに関するメタデータを安全に client や認可サーバーとやり取りするための仕様
- MCP仕様では、主にMCPクライアントが認可サーバーの場所を特定する目的で言及されているように見えます
- [MUST] MCPクライアントは Resource Indicators RFC8707) を実装する
- クライアントがアクセス要求をしている対象リソースを、認可サーバーに対して明示する仕様
- これにより、認可サーバーは認可時にリソースを検証でき、またリソースサーバー側も自身を対象としていないアクセストークンを拒否できるようになります
- [MUST] MCPサーバーは、渡されたトークンが自身のために発行されているか検証すること
要はある程度の利便性を担保しつつ、発行したトークンが意図しないリソースサーバーに使われないようにいくつかの仕様をサポートしている、というかんじです。
課題
MCPツールとユーザー個人の間で認可が行われるので、管理者がMCPツールの利用状況や、与えられている認可の状況を把握できません。
また、ユーザー個人が認可を許可するので、理屈上従業員が可能な操作についての認可は全て与えられる可能性があります。
管理者目線からすると、予期せぬMCPツールから予期せぬデータ参照/書き込みが起こる可能性があり困ってしまいます。
たとえば悲観的には、権限が強めなユーザーがなんかMCPツール使ってたんだけど、暴走してgoogle driveの内容全部吹っ飛びました、みたいなことが起こりえます。
このあたりは組織ごとにポリシーもありそうで、悲観的なシナリオを鑑みて「MCPは色々やられうるので、最小権限での認可は大前提としてそもそもMCPに使わせたくないリソースは拒否したい」などのニーズもありそうです。
今のユーザーとMCP認可サーバー間の認可では、ユーザーにできることは理論上全て認可可能なので、特定リソースの利用を拒否するような設定を一貫して行うことはできません。
ようは管理者によって「管理できない、確認できない、制御できない」が企業利用だと課題になりえるわけです。
エンタープライズ向けの認可仕様の提案があるぞ！
Okta の人がMCPにおけるエンタープライズ向けの認可仕様として、こんな提案をしています！
SEP-646: Enterprise-Managed Authorization Profile for MCP
これは今絶賛ドラフト中の Identity Assertion JWT Authorization Grant(ID-JAG) の仕組みをベースにしています。
このドラフトがどういうものかというと、要するに「リソースサーバーと認可サーバーが、あるIdPに安全に認可を移譲する」ことを可能とするような仕様です。
エンタープライズ企業は多くの場合信頼できるIdPでアカウント管理をしており、SSOなどの仕組みも整っていることが多いです。
その流れで各ツールとの認可もIdPに移譲して管理するのは、流れとしては自然なように思います。
PRにある仕様提案の図をそのまま引用すると以下です。
ざっくり流れを書くと以下の感じです
- MCPクライアント - IdP 間でIDトークンを発行
- MCPクライアント - IdP 間で先ほど発行したIDトークンを用いて ID-JAG の仕組みを使って Assertion Token を取る
- 「どのMCPリソースサーバーにむけて、どのようなscopeで認可要求がきたのか」が IdP に渡されるので、IdP はそれを確認し署名をする
- MCPクライアント - MCP認可サーバー間で ID-JAG で発行した Assertion Token を渡して access token を取得する
- このとき Assertion Token は IdP によって署名されておりMCP認可サーバーにて検証可能
- この署名検証を持って、ある認可リクエストがIdPによって許可されていることがわかる！認可サーバーは認可を IdP の判断に移譲する
- 検証がパスしたらMCP認可サーバーはMCPリソースサーバーにむけたアクセストークンを発行する
- このとき Assertion Token は IdP によって署名されておりMCP認可サーバーにて検証可能
- MCPクライアントは、発行したアクセストークンを使ってMCPリソースサーバーにリクエスト
このシーケンスでは認可サーバーは認可を IdP に移譲していて、確認取れた内容に従ってアクセストークンを吐く流れになっています。
何が嬉しいか
2つ嬉しいポイントがあります！
ひとつは、企業の管理者側がMCPに関連する認可を企業全体で統制、コントロールできることです。
具体的には、IdPを介して、組織内でどのようなMCPツールにどのような認可まで与えて良いのかを制御することが可能です。また、利用を許可しているMCPツール状況を可視化することもできます。
もうひとつは、ユーザー側でインタラクティブな consent のような処理が挟まれないことが挙げられます。
いち従業員としては、どのツールにどこまで認可を与えて良いか判断がつかないケースもあり得るので、管理者によって設定されたIdPの判断に移譲できるのは安全かつ利便性が高いです。
提案を読んだ感想
全体的に方針自体はかなり良さそうに感じました！
エンタープライズ管理者は中央集権的に各種リソースに対する認可を一元管理したいニーズがあるので、安全な形でそれをサポートできるなら喜ぶ人は多そう！
ただ、この仕組みで厳密な管理を実現するためには、以下を全て満たす必要がありそうです。
- MCP認可サーバーが仕様をサポートすること
- IdPが仕様をサポートすること
- 社内で利用するすべてのMCPツールにおいて、MCP認可サーバー側で ID-JAG 以外の認可を禁止する設定が可能なこと
とくに最後が重要かつ困難だと思っていて、迂回した認可が可能だと結局そこからIdPが把握できない認可がされうるので困りそうです。
仮にMCP認可サーバー側で認可を禁止する設定が可能だとしても、個々人がさまざまなMCPツールの利用を試みるケースを考えると、事前に企業全体で利用しうるMCPツールすべてを列挙することが現実的でなく、そこは課題になりそうです。
とはいえ、この仕組みを導入できる環境が整えば、管理者は「ユーザー」と「MCPツール」の組み合わせで認可を細かく設定できるため、柔軟な制御が実現できそうです。
例えば、「開発部門のユーザーであれば、どのMCPツールを使ってもGitHub関連リソースへのread権限までは許可する」、その上で「会社として正式に許可した特定のMCPツールに限り、write権限も許容する」、といった高度なポリシーを管理者が組織全体に展開することが可能になります。
あと、管理者があるMCPツールに対して与えうる認可範囲を制御できるのは嬉しいのですが、実際設定可能っすよと言われても管理者は「外部ツールのscope体系とか正直わからん！」となりそうなのが懸念ですかね。Protected Resource Metadata (RFC9728) の仕様から、実装されていればサポートされる scope などは取れるはずですが、それぞれがどう作用するか管理者が正しく把握していないと設定は難しいはずです。
管理者側の最初の設定が大変そうだな〜という気配があって、そこは IdP 側が設定画面を練るなどして頑張ったりするのかな〜
今回の提案仕様はベースとなる ID-JAG 自体がドラフトなのもあり、エコシステム全体で実装が進むのはもう少し時間がかかりそうではありますが、個人的には方針に納得感があり、さらなる発展を期待しています。
さいごに
今回はエンタープライズ向け認可にまつわるMCP仕様への提案 SEP-646: Enterprise-Managed Authorization Profile for MCP をみていきました。
実運用に向けてはまだいくつか課題が感じられるものの、IdP を中心として整理がなされていくのは企業ニーズからすると妥当な気がしています。
該当提案や関連のInternet-Draftは引き続きウォッチしようかな〜と思いました。
このあたりは最新議論の動向をウォッチしつつ、リスクを鑑みた上で自分たちはどこまで整理するかを判断できると良いですね。がんばるぞ〜
一緒にこのあたり整理して実装していく機会がこれからたくさんありそうなので、興味ある方ぜひお話しさせてください〜
絶賛メンバー募集中でもあるので、興味ある方はこちらもぜひ〜〜
Discussion