MCP の仕様 (6) - 基本プロトコル - 認可

以下の記事が面白かったので、簡単にまとめました。

前回

1. 認可

1-1. 目的と範囲

モデルコンテキストプロトコル（MCP）は、トランスポートレベルでの認可機能を提供し、MCPクライアントがリソース所有者に代わって制限付きMCPサーバにリクエストを送信できるようにします。この仕様は、HTTPベースのトランスポートにおける認可フローを定義します。

1-2. プロトコル要件

MCP実装における認証はオプションです。サポートされている場合

1-3. 標準準拠

この認可メカニズムは、以下に示す既存の仕様に基づいていますが、シンプルさを維持しながらセキュリティと相互運用性を確保するために、これらの仕様の一部の機能のみを実装しています。

2. 認可フロー

2-1. 役割

保護されたMCPサーバは、アクセストークンを使用して保護されたリソースリクエストを受け入れ、応答する機能を持つOAuth 2.1リソースサーバとして機能します。

MCPクライアントはOAuth 2.1クライアントとして機能し、リソースオーナーに代わって保護されたリソースリクエストを行います。

認可サーバは、ユーザーとのやり取り (必要に応じて) と、MCPサーバで使用するアクセストークンの発行を担当します。認可サーバの実装の詳細は、この仕様の範囲外です。認可サーバは、リソースサーバと共にホストされることもあれば、別のエンティティとしてホストされることもあります。「認可サーバの検出」セクションでは、MCPサーバが対応する認可サーバの場所をクライアントに示す方法を規定します。

2-2. オーバービュー

2-3. 認可サーバの検出

このセクションでは、MCPサーバが関連付けられた認可サーバをMCPクライアントに通知するメカニズムと、MCPクライアントが認可サーバのエンドポイントとサポートされている機能を判別できる検出プロセスについて説明します。

・認可サーバの場所
MCPサーバは、認可サーバの場所を示すために、OAuth 2.0 保護リソースメタデータ (RFC9728) 仕様を実装しなければなりません。MCPサーバから返される保護リソースメタデータドキュメントには、少なくとも1つの認可サーバを含む authorization_servers フィールドが含まれていなければなりません。

authorization_servers の具体的な使用法はこの仕様の範囲外です。実装者は、実装の詳細に関するガイダンスとして、OAuth 2.0 保護リソースメタデータ (RFC9728) を参照してください。

実装者は、保護リソースメタデータドキュメントで複数の認可サーバを定義できることに留意してください。使用する認可サーバの選択は、RFC9728 セクション7.6「認可サーバ」に規定されているガイドラインに従い、MCPクライアントが責任を負います。
MCPサーバは、RFC9728 セクション5.1「WWW-Authenticate Response」に規定されているように、リソースサーバメタデータURLの場所を示すために、401 Unauthorized を返す際にHTTPヘッダー WWW-Authenticate を使用する必要があります。

MCP クライアントは、WWW 認証ヘッダーを解析し、MCP サーバからの HTTP 401 不正応答に適切に応答できる必要があります。

・サーバメタデータ検出
MCPクライアントは、認可サーバとのやり取りに必要な情報を取得するために、OAuth 2.0認可サーバメタデータRFC8414仕様に従う必要があります。

・シーケンス図
次の図は、フローの例を示しています。

2-4. 動的クライアント登録

MCPクライアントと認可サーバは、OAuth 2.0 動的クライアント登録プロトコル（RFC7591）をサポートする必要があります。これにより、MCPクライアントはユーザーの介入なしにOAuthクライアントIDを取得できます。これにより、クライアントが新しい認可サーバに自動的に登録するための標準化された方法が提供されます。これはMCPにとって非常に重要であり、以下の理由から重要です。

動的クライアント登録をサポートしない認可サーバは、クライアントID（および該当する場合はクライアント資格情報）を取得するための代替手段を提供する必要があります。これらの認可サーバのいずれかに対して、MCPクライアントは次のいずれかを行う必要があります。

2-5. 認可フローの手順

認可フロー全体は次のように進行します。

・リソースパラメータの実装
MCPクライアントは、RFC 8707で定義されているOAuth 2.0のリソースインジケータを実装し、トークンの要求対象となるリソースを明示的に指定する必要があります。リソースパラメータは以下のとおりです。

・正規サーバURI
本仕様では、MCPサーバの正規URIは、RFC 8707セクション2で規定されているリソース識別子として定義され、RFC 9728のリソースパラメータと一致します。

MCPクライアントは、RFC 8707のガイダンスに従い、アクセスするMCPサーバに対して可能な限り具体的なURIを提供すべきです。正規形式では小文字のスキームとホストコンポーネントを使用しますが、実装では堅牢性と相互運用性のために大文字のスキームとホストコンポーネントを受け入れるべきです。

・有効な正規URIの例

・無効な正規URIの例

たとえば、https://mcp.example.com の MCP サーバにアクセスする場合、認証リクエストには次の内容が含まれます。

&resource=https%3A%2F%2Fmcp.example.com

MCP クライアントは、認可サーバがサポートしているかどうかに関係なく、このパラメータを送信する必要があります。

2-6. アクセストークンの使用

・トークンの要件
MCPサーバへのリクエストを行う際のアクセストークンの取り扱いは、OAuth 2.1セクション5「リソースリクエスト」で定義されている要件に準拠する必要があります。具体的には以下のとおりです。

(1) MCP クライアントは、OAuth 2.1 セクション 5.1.1 で定義されている Authorization リクエスト ヘッダー フィールドを使用する必要があります。

Authorization: Bearer <access-token>

同じ論理セッションの一部であっても、クライアントからサーバへのすべての HTTP リクエストに認証を含める必要があることに注意してください。

(2) アクセストークンはURIクエリ文字列に含めないでください。

GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

・トークン処理
OAuth 2.1 リソースサーバとして機能する MCP サーバは、OAuth 2.1 セクション 5.2 に記載されているようにアクセストークンを検証する必要があります。MCP サーバは、RFC 8707 セクション 2 に従い、アクセストークンが対象ユーザーとして自身に発行されたことを検証する必要があります。検証に失敗した場合、サーバは OAuth 2.1 セクション 5.3 のエラー処理要件に従って応答する必要があります。無効または期限切れのトークンは、HTTP 401 レスポンスを受信する必要があります。

MCP クライアントは、MCP サーバの認可サーバによって発行されたトークン以外のトークンを MCP サーバに送信してはなりません。
認可サーバは、自身のリソースで使用できる有効なトークンのみを受け入れなければなりません。

MCP サーバは、その他のトークンを受け入れたり、通過させたりしてはなりません。

2-7. エラー処理

サーバは、認証エラーに対して適切な HTTP ステータスコードを返す必要があります。

3. セキュリティに関する考慮事項

実装は、OAuth 2.1 セクション 7「セキュリティに関する考慮事項」に記載されている OAuth 2.1 セキュリティのベストプラクティスに従う必要があります。

3-1. トークンオーディエンスのバインディングと検証

RFC 8707 リソースインジケーターは、認可サーバがこの機能をサポートしている場合、トークンを対象オーディエンスにバインディングすることで、セキュリティ上の重要なメリットをもたらします。現在および将来の導入を可能にするために、以下の点に留意してください。

セキュリティベストプラクティスドキュメントでは、トークンオーディエンスの検証が重要である理由と、トークンパススルーが明示的に禁止されている理由について概説しています。

3-2. トークンの盗難

クライアントによって保存されたトークン、またはサーバにキャッシュまたはログに記録されたトークンを入手した攻撃者は、リソースサーバにとって正当なリクエストに見えるリクエストで保護されたリソースにアクセスできます。

クライアントとサーバは、OAuth 2.1 セクション 7.1 に記載されているように、安全なトークンストレージを実装し、OAuth のベストプラクティスに従う必要があります。

認可サーバは、トークン漏洩の影響を軽減するために、有効期間の短いアクセストークンを発行する必要があります。パブリッククライアントの場合、認可サーバは、OAuth 2.1 セクション 4.3.1「トークンエンドポイント拡張」に記載されているように、リフレッシュトークンをローテーションする必要があります。

3-3. 通信セキュリティ

実装は、OAuth 2.1 セクション 1.5「通信セキュリティ」に従わなければなりません。

3-4. 認可コードの保護

認可レスポンスに含まれる認可コードにアクセスした攻撃者は、認可コードをアクセストークンと引き換えたり、その他の方法で認可コードを利用しようと試みる可能性があります。(詳細はOAuth 2.1 セクション7.5で説明されています)

これを軽減するために、MCPクライアントはOAuth 2.1 セクション7.5.2に従ってPKCEを実装する必要があります。PKCEは、クライアントに秘密の検証子とチャレンジのペアの作成を要求することで認可コードの傍受やインジェクション攻撃を防ぎ、元のリクエスト元のみが認可コードをトークンと交換できるようにします。

3-5. オープンリダイレクト

攻撃者は悪意のあるリダイレクトURIを作成し、ユーザーをフィッシングサイトに誘導する可能性があります。

MCPクライアントは、認可サーバにリダイレクトURIを登録する必要があります。

認可サーバは、リダイレクト攻撃を防ぐため、事前に登録された値と照らし合わせてリダイレクトURIの正確性を検証する必要があります。
MCPクライアントは、認可コードフロー内の状態パラメータを使用および検証し、元の状態を含まない、または元の状態と一致しない結果を破棄する必要があります。

認可サーバは、OAuth 2.1 セクション7.12.2に示されている提案に従い、ユーザーエージェントを信頼できないURIにリダイレクトしないための予防措置を講じる必要があります。

認可サーバは、リダイレクトURIを信頼している場合にのみ、ユーザーエージェントを自動的にリダイレクトする必要があります。URIが信頼されていない場合、認可サーバはユーザーに通知し、ユーザーが正しい判断を下すことを信頼しても構いません。

3-6. Confused Deputy問題

攻撃者は、サードパーティAPIの仲介役として機能するMCPサーバを悪用し、Confused Deputy脆弱性を引き起こす可能性があります。盗んだ認可コードを使用することで、ユーザーの同意なしにアクセストークンを取得できます。

静的クライアントIDを使用するMCPプロキシサーバは、動的に登録されたクライアントごとに、サードパーティ認可サーバ (追加の同意が必要となる場合があります) に転送する前に、ユーザーの同意を得る必要があります。

3-7. アクセストークンの権限制限

MCPサーバが他のリソース用に発行されたトークンを受け入れる場合、攻撃者は不正アクセスを取得したり、サーバを侵害したりする可能性があります。
この脆弱性には、2つの重要な側面があります。

MCPサーバは、リクエストを処理する前にアクセストークンを検証し、アクセストークンがMCPサーバ専用に発行されていることを確認するとともに、権限のない第三者にデータが返されないように必要なすべての手順を踏まなければなりません。

MCPサーバは、OAuth 2.1のセクション5.2のガイドラインに従って、受信トークンを検証しなければなりません。

MCPサーバは、自身に向けられたトークンのみを受け入れなければならず、Audienceクレームに自身が含まれていないトークン、またはトークンの本来の受信者であることを確認しないトークンは拒否しなければなりません。詳細については、「セキュリティのベストプラクティス」の「トークンパススルー」セクションを参照してください。

MCP サーバがアップストリーム API にリクエストを行う場合、MCP サーバはそれらの API に対して OAuth クライアントとして機能することがあります。アップストリーム API で使用されるアクセストークンは、アップストリーム認可サーバによって発行される別のトークンです。MCP サーバは、MCP クライアントから受信したトークンをパススルーしてはなりません（MUST NOT）。

MCP クライアントは、RFC 8707 - Resource Indicators for OAuth 2.0 で定義されているリソースパラメータを実装して使用し、トークンの要求対象となるリソースを明示的に指定する必要があります（MUST）。この要件は、RFC 9728 セクション 7.4 の推奨事項と一致しています。これにより、アクセストークンが意図されたリソースにバインドされ、異なるサービス間で悪用されることが防止されます。