MCPサーバーを本番に持ち込む段階で、認可設計の選択肢が複数あることに気づき実装が止まる。Dynamic Client RegistrationとClient ID Metadata Documents、どちらが適切か。スコープをどう粒度で設計し、トークン有効期限切れにどう対応するか。MCP仕様（2026年時点のdraft）はOAuth 2.1を基盤に、これらすべての設計判断に規範的な答えを与えている。

MCP（Model Context Protocol）の認可仕様はエージェントガバナンスの技術基盤として位置づけられる。サーバー実装の基礎についてはMCPサーバー実装ガイドも参照してほしい。

MCPの認可モデル——OAuth 2.1が前提となった理由

MCPの認可はOAuth 2.1 draftを必須標準とし、HTTPトランスポートでの保護リソースアクセスを規定する。STDIOでは環境変数から認証情報を取得する別経路を設ける。

OAuth 2.1が採用された理由は明快だ。OAuth 2.0の実装で頻発したImplicit FlowやResource Owner Password Credentials Flowのセキュリティ上の問題をゼロにするため、OAuth 2.1ではPKCE（Proof Key for Code Exchange）が全フローで必須化され、安全でないフローは廃止された。MCPサーバーが外部に公開されるエージェント基盤である以上、アクセストークン詐取リスクには設計段階で対処する必要がある。

MCP認可アーキテクチャのロールは3つだ。MCPサーバーはOAuth 2.1リソースサーバーとして機能しアクセストークンを検証する。MCPクライアントはリソースオーナーを代行してリクエストを行うOAuth 2.1クライアントだ。認可サーバーはトークンを発行する独立エンティティで、MCPサーバーと同居することも分離することもできる。

Protected Resource MetadataとAuthorization Server Discovery

MCPサーバーはRFC 9728に準拠したProtected Resource Metadataを必須実装し、クライアントがこのメタデータを起点に認可サーバーを自動発見する。

MCPクライアントがトークンなしでリクエストを送ると、MCPサーバーはHTTP 401 Unauthorizedを返す。このレスポンスのWWW-Authenticateヘッダーにはresource_metadataパラメーターが含まれており、クライアントはそのURLに問い合わせてProtected Resource Metadataドキュメントを取得する。これが認可サーバー発見フローの起点だ。

``http HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"``

Protected Resource Metadataのauthorization_serversフィールドから認可サーバーのエンドポイントを特定し、MCP仕様が要求する2つのディスカバリーメカニズム（OAuth 2.0 Authorization Server Metadata [RFC 8414] と OpenID Connect Discovery 1.0）でメタデータを取得する。クライアントは両方に対応しなければならない。

クライアント登録の経路は優先度順に以下の3つだ。

Client ID Metadata Documents（推奨）: クライアントはHTTPS URLをclient_idとして使用し、認可サーバーがそのURLからJSONメタデータを取得する。
事前登録（Pre-registered client）: 既存のクライアントIDを使用する。
Dynamic Client Registration（RFC 7591）: 後方互換のために残されているが非推奨。

スコープ設計の最小権限戦略

MCPのスコープ選択はWWW-Authenticateヘッダーのscope値を最優先とし、段階付与フローで必要最小限の権限を逐次取得する設計が基本だ。

仕様が定めるスコープ選択の優先順位は2段階だ。まず401レスポンスのWWW-Authenticateヘッダーにscopeパラメーターがある場合はそれを使用する。なければProtected Resource Metadataのscopes_supportedに列挙されたすべてのスコープを要求する。scopes_supportedはMCPサーバーの基本機能に最低限必要なスコープセットを表す設計が推奨される。

スコープのネーミング規則としてfiles:read・files:write・users:adminのようにリソース:アクション形式を採用すると、403レスポンスでの不足スコープの明示とクライアント側のパースが容易になる。スコープ不足時のレスポンス例：

``http HTTP/1.1 403 Forbidden WWW-Authenticate: Bearer error="insufficient_scope", scope="files:write", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", error_description="File write permission required for this operation"``

設計上の落とし穴として、スコープを細かく分割しすぎて単一操作に必要なスコープを複数の403ラウンドトリップで取得させてしまうパターンがある。MCP仕様は「現在の操作に必要なすべてのスコープを1回のチャレンジで返すべき」と明記している。クライアント側はStep-Up Authorization Flowを実装し、受け取ったスコープと過去に取得済みのスコープの和集合を計算して再認可リクエストを発行する。

Resource Indicatorsによるトークン束縛

MCPクライアントはRFC 8707のresourceパラメーターを認可・トークンリクエスト両方に必須で含め、トークンが特定サーバーだけに有効であることを保証する。

Resource Indicators（RFC 8707）はMCP認可設計において特に重要な仕様だ。resourceパラメーターにMCPサーバーの正規URIを指定することで、そのトークンが指定サーバー以外では使用不可能になる。複数のMCPサーバーが存在する環境でのトークン流用攻撃の防止に直結する。

```
# Authorization request
...&resource=https%3A%2F%2Fmcp.example.com&code_challenge=...

Token request

resource=https://mcp.example.com&code_verifier=... ```

正規URIの構成ルール：httpsスキーム＋ホスト＋必要に応じてパスの形式を使用する。フラグメント（#以降）は含めない。末尾スラッシュなしの形式（https://mcp.example.com）を推奨する。

MCPサーバー（リソースサーバー）はトークン受信時に以下の項目を検証する義務がある。

署名またはトークンイントロスペクションによる正当性確認
発行者（issuer）の一致
有効期限（expiry）のチェック
オーディエンス（audience）バインディング確認
Resource Indicators（RFC 8707）によるリソース束縛確認
スコープの十分性
失効ステータス（サポートする場合）

検証失敗はHTTP 401を返す。スコープ不足はHTTP 403を返し必要スコープをWWW-Authenticateヘッダーに明示する。不正な認可リクエストはHTTP 400を返す。

エンタープライズ規模のMCPサーバー基盤設計・社内認可サーバーとのOAuth 2.1統合・複数チームへのデプロイ体制についてはKuuのRDEサービスが支援している。

参考

まとめ

MCPサーバーのOAuth 2.1認可設計は5要素で構成される。①Protected Resource Metadata（RFC 9728）の実装、②PKCE必須のAuthorization Code Flow、③Client ID Metadata Documents優先のクライアント登録、④Resource Indicators（RFC 8707）によるトークン束縛、⑤Step-Up Authorization Flowによるスコープの段階付与だ。これらを正しく組み合わせることで、エージェントが正規のMCPサーバーにのみアクセスできる安全な認可基盤が完成する。

認可設計・企業内認可サーバーとの統合・マルチテナントMCPデプロイに課題を感じている場合は、KuuのRDEサービスにご相談ください。

MCPサーバーのOAuth 2.1認可フロー——スコープ設計指針