MCPの認可に画期的な仕様が追加された

MCPの認可(Authorization)仕様の一つとして「Dynamic Client Registration」があり、これを実現するのはつらみがありますが、最近 「SEP-1036: URL Mode Elicitation for secure out-of-band interactions」 という仕様変更が承認されたことで「Dynamic Client Registration」をしない方法も可能となったようです。

先日書いた「最近のMCPの仕様拡張（2025年9月）」という記事の中で、この「SEP-1036」について軽く紹介しましたが、今回は「SEP-1036」にフォーカスして詳しく説明をしてみようと思います。もし記事の中で間違っていることがあればご指摘ください。

今までの MCP Authorization の仕様

まずはじめに、最新版のMPCの仕様（バージョン：2025-06-18）をおさらいしてみます。簡単のため説明を意図的に省いている箇所はありますが、大きな流れとしては次の図のようになっています。

図を見ると分かる通り、ざっくりと次のような流れになっています。

1. 認可サーバーの検出フロー
2. Dynamic Client Registration
3. Authorization Code Grantフロー
4. 取得したアクセストークンを使う

MCPの「Authorization」の仕様として「Dynamic Client Registration」は「SHOULD」となっているので、必ず実装が必要な仕様ではないのですが、ユーザーの利便性を考えると実装したい仕様でもあります。しかし一方で、企業ユースでは「Dynamic Client Registration」は使いにくいというデメリットもあり悩ましい問題でした。

SEP-1036: URL Mode Elicitation for secure out-of-band interactions

MCPの認証認可についてはこれまで様々な要望や議論があったようで、それらの要望に対応できるよう、柔軟な認証認可の仕組みとして「SEP-1036: URL Mode Elicitation for secure out-of-band interactions」という仕様拡張提案が提出されました。

現在このissueは承認されていますが、PRについてはまだレビュー中のため、MCPの仕様には反映されるのはしばらく先になりそうです（まだdraftバージョンにも入っていません）。

では具体的にどういう拡張が入るのかを確認して行きましょう。

仕様拡張提案のタイトルは「SEP-1036: URL Mode Elicitation for secure out-of-band interactions」となっていて、タイトルの通り「Elicitation」という仕様に「URL Mode」を追加する提案です。

まずは「Elicitation」とはどういったものかを説明していきます。

Elicitation とは

ElicitationとはMCPサーバーがMCPクライアントを介してユーザーに追加情報を要求するための仕組みです。具体的には次のフロー図のようになっていて、MCPサーバーが要求をすることでフローが開始します。

例えばMCPサーバー側が「ユーザーの名前」を知りたくなったとした場合、MCPクライアントを通じてユーザーが対話式に「ユーザーの名前」を回答する、といった形でElicitationが利用されているようです。

Elicitation に追加される URL Mode とは

このElicitationという仕様に対し「SEP-1036: URL Mode Elicitation for secure out-of-band interactions」では「URL Mode」という仕様を追加します。

前述の通り、今まではMCPクライアントを経由して情報を入力しており、それを「Form Mode」と呼ぶこととし、対して、今回追加される「URL Mode」では、MCPクライアントがブラウザを開き、ユーザーがブラウザを通じて情報を入力できるようになります。

• フォーム モード(in-band): MCPサーバーは、MCPクライアントを経由してユーザーから情報を収集できる
• URL モード(out-of-band): MCPサーバーは、MCPクライアントを通過してはならない機密性の高いやり取りのために、ユーザーを外部URLに誘導することができる

ちょっと難しい説明になってしまいましたが、簡単にいうと 「MCPクライアント」 が 「ブラウザ」 を起動するようになります。

そしてこの時 「MCPクライアント」 と 「ブラウザ」 がうまく連動することで、セキュリティを保ちつつ、より柔軟なユーザー体験を提供できるようになります。具体的に想定されるユースケースとしては、支払いやサブスクリプションなどが想定されているようです。

さて「URL Mode」がどういったものか分かったところで、話をMCPの認証認可に戻そうと思います。
この「URL Mode」は認証認可とどのように関係があるのでしょうか。

URL Mode を認証認可に応用する

ここまで説明してきた「URL Mode」という新しい仕様は、ブラウザを開くことができるとても柔軟な仕組みなので、MCPの認証認可にも使うことができます。

具体的に１つ例を挙げると、次の図のようなフローを考えられます。

注目ポイント：

• MCPサーバーが OAuth Client として動作している（MCPサーバーがアクセストークンを保持している）
• MCPクライアントはClientID、ClientSecretなどの情報を持つ必要がない
• MCP Authorizationを使っていないので local MCP でもこの仕組みを利用可能（MCP Authorizationは仕組み上 remote MCP 専用だったはず）

これはあくまで一例なので、もちろん認証認可以外の用途にも「URL Mode」を使うことが可能です。

終わり

まだ実際にMCPの仕様に反映されていないため、今後仕様が変わる可能性もありますが、私はこの「SEP-1036」のPRを見てとても可能性のある仕組みだなと感じました。

ここまで私の理解を説明してきましたが、まだ新しい仕様ということもあり私の理解が間違っている可能性もあるので、もし間違いがあればご指摘いただければと思います。

以上です。