これははてなエンジニア Advent Calendar 2025、8日目の記事です。
Model Context Protocol (MCP)の登場で、AIアプリケーションが外部システムを呼び出し、情報を参照する手続きの標準化が進んでいる。
MCPサーバーのトランスポート層として、ローカル利用を想定したstdio（標準入出力）に加え、HTTPを利用するStreamable HTTPが定義されている。このStreamable HTTPにおいて、ユーザーに紐づくプライベートな情報を扱うために避けて通れないのが、認可（Authorization）の仕組みである。
本記事は2025年11月25日に公開されたMCPの最新仕様（2025-11-25）に基づく。
MCPの認可基盤としての「OAuth 2.1」
MCPの認可仕様（Authorization）は、IETFの標準技術（とそのドラフト）に立脚している。
- OAuth 2.1 IETF DRAFT (draft-ietf-oauth-v2-1-13)
- OAuth 2.0 Authorization Server Metadata (RFC8414)
- OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
- OAuth 2.0 Protected Resource Metadata (RFC9728)
- OAuth Client ID Metadata Documents (draft-ietf-oauth-client-id-metadata-document-00)
その中心となるのがOAuth 2.1だ。
OAuth 2.1は、広く普及しているOAuth 2.0のベストプラクティスを取り込み、セキュリティを強化した改訂版である。
MCPのアーキテクチャとOAuth 2.1を対応づけると、MCPリモートサーバーがOAuth 2のリソースサーバー、アカウントシステムがOAuth 2の認可サーバーとなる。これらは単一のシステムでもよいし、別々でもよい。
OAuth 2は、認可プロトコルとしては、おそらく最もひろく利用されており、十分に枯れている。MCPに限らず、およそ認可という仕組みが必要なHTTPベースのシステムはすべて、OAuth 2を採用するのが自然だ。
メタデータによるディスカバリ
MCPクライアントとしてのAIアプリケーションは、数多のMCPサーバーと接続する可能性があり、それぞれについて予め詳細を知っておくことは不可能だ。これを解決するために、認可サーバーは「OAuth 2.0 Authorization Server Metadata」を、リソースサーバーは「OAuth 2.0 Protected Resource Metadata」に準拠している必要がある。
OAuth 2.0 Authorization Server Metadataは、認可サーバーの仕様をJSONで提供するもので、ふつう認可サーバーの /.well-known/oauth-authorization-server で配信する。このメタデータからは、認可フローで利用する各エンドポイントのURLはもちろん、認可サーバーが対応している様々なパラメータが把握できる。
これに対してOAuth 2.0 Protected Resource Metadataは、リソースサーバーの仕様をJSONで提供する。MCPの文脈では特に、認可サーバーや対応するスコープを示すのに使われる。リソースサーバーの /.well-known/oauth-protected-resource で配信する。スコープの選択に関しては難しい問題があるが、それは後述する。
これによって、MCPクライアントは動的に認可の仕様を取得し、適切に認可フローを開始できる。
クライアントの登録
ここまでの対応は、通常のOAuth 2の対応でも普通に行われることが多い。通常、OAuth 2に対応するサーバー・クライアントでは、事前にクライアントを認可サーバーに登録し、Client IDを取得する。これはクライアントが予め認可サーバーのことを知っておけるから成立している。
MCPでは、MCPクライアントは事前にMCPサーバーの詳細を知らないという前提がある。MCPという標準があることで、予め詳細を共有しておく必要がない。このために、クライアントを認可サーバーに登録するのも動的に行える方がよい。
動的クライアント登録
OAuth 2.0 Dynamic Client Registration Protocolは、動的クライアント登録（DCR）と呼ばれる仕様で、まさにこの問題を解決するためにある。そもそもDCRはOpenID Connect（OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2）に由来している。OpenID ConnectもMCPと同様、標準があることで、サーバーとクライアントの関係を疎にできることで、DCRを行うモチベーションがあるのだろう。
ただしDCRは、一般にはあまり実装されていない。任意のクライアントを動的に登録できるのは、認可サーバーから見れば、管理上の負荷が増える可能性もあり、好まれない。これを受けて、MCPの最新版で加わったのが、次に説明するOAuth Client ID Metadata Documentsである。
Client ID Metadata Documents
OAuth Client ID Metadata Documents（CIMD）のRFCはまだドラフト段階だが、MCPの最新の仕様で採用された。CIMDでは、クライアントを登録するのではなく、クライアントの情報を記したJSONのURLをClient IDとして使用する。認可サーバーは受け取ったClient IDがURLであれば、これをCIMDに準拠したクライアントだと認識し、URLからクライアント情報を取得する。
CIMDは突飛な発想のようにも思えるが、意外なほどうまく機能する。予めクライアントを登録する必要もなければ、クライアント情報を無制限に保存する必要もない。Client IDとリダイレクトURIのオリジンを比較することで、無関係なクライアント情報で誤認させるような攻撃も防ぎやすい。
クライアント登録の順序
仕様では次の順序でクライアント登録する方法を定めている(§5 Client Registration Approaches)。
- もし予め用意したクライアント情報があればそれを利用する
- 認可サーバーがCIMDに対応していればそれを利用する
- DCRにフォールバックする
- クライアント情報がないかユーザーに確認する
CIMDは最新の仕様で追加されたのもあり、現在のところ対応はあまり広がっていない。よく使われているところではVS Codeでの対応が知られており、Client IDは https://vscode.dev/oauth/client-metadata.json となっているようだ。今後は採用が広がるだろうと思われるので、認可サーバーでの対応を検討しておきたい。
DCRもCIMDも、事前に登録されたクライアントではないクライアントからの利用を受け付けることになるため、セキュリティやポリシーなどをよく検討しなければならない。
スコープの選択
ところで、MCPと同様にサーバーとクライアント間のやり取りが標準化されているOpenID Connectでは、使用するOAuth 2スコープが openid や profile のように標準化されている。このことで、クライアントはリソースサーバーのスコープの詳細に立ち入らずに済む。
一方MCPでは、リソースサーバーがどのようなOAuth 2スコープを受け付けているか知る必要がある。仕様ではMCPクライアントがどのようにスコープを選択すべきか定められており（§6 Scope Selection Strategy）、次の優先順位で採用することになっている。
- リソースサーバーが401を返した際の
WWW-Authenticateヘッダのscopeパラメータを参照する - OAuth 2.0 Protected Resource Metadataで表明された、リソースサーバーがサポートするスコープを参照する
これで済めば話は簡単だが、実際の運用ではもう少しややこしい。OAuth 2.1では明確に規定されていない（実装に委ねられている）が、多くの認可サーバーの実装では、クライアントに予めスコープを設定し、認可フローで要求できるスコープはそのサブセットでなくてはならないという制約を課す。DCRでもそういったケースが考慮されたのか、動的に登録できるクライアント情報に scope パラメータが含まれている。ClaudeのMCPクライアントとしての実装では、実際に、DCRの際にリソースサーバーに合わせたスコープを要求するのを確認した。一方CIMDではその仕様上、リソースサーバーに合わせてスコープを要求するのは困難だ。
従って、認可サーバーではクライアントのスコープが空のとき、MCPで利用する可能性のあるスコープ全てをデフォルトスコープとして設定する、というような実装をすることになるかもしれない。
まとめ
MCPのように、標準化されたプロトコルに則って認可の必要なHTTPベースのAPIアクセスを提供する場合、APIを提供するリソースサーバーや認可サーバーは、OAuth 2やそれに関連する認可プロトコルを実装しなければならない。MCPの仕様はbest current practice的なものになっている。
もし皆さんがアカウントシステムを開発・運用しているなら、OAuth 2.1を筆頭に、これらの標準に則った実装を行う必要があるかもしれない。
