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サービスが支援している。

M2Mフローの設計——Client Credentialsによるバックグラウンドアクセス

ユーザー同意が不要なバックグラウンドエージェントや定期実行には、Client Credentialsフローを使いユーザーフローとクライアントを分離して管理します。

MCPの認可フローは用途によって2つに分かれる。Authorization Code + PKCEはエンドユーザーの明示的同意が必要な操作（メール送信・ドキュメント編集など）に適用する。これに対してClient Credentials（RFC 6749 §4.4）は、cronジョブ・バックグラウンドエージェント・A2Aプロトコル経由のエージェント間連携など、ユーザー介在なしの処理を対象とする。

Client Credentialsフローの設計指針は次の3点だ。

クライアントの分離: ユーザーフローと同じOAuthクライアントIDをM2Mフローに使い回さない。フローごとに別のクライアントを発行することで、監査ログで呼び出し元を区別でき、クライアント単位の失効・ローテーションが可能になる
シークレット管理: client_secret はvaultで管理しローテーション周期を90日以内に設定する。ソースコードや環境変数への直埋めは禁止
refresh tokenなし: Client Credentialsフローでは refresh_token は発行されない。有効期限切れのたびにトークンを再取得するロジックをエージェント実装に組み込む

MCP仕様は2025年11月改訂（SEP-1046）でM2Mフローのサポートを明文化しており、エンタープライズでのヘッドレスエージェント運用が標準的なユースケースとして位置付けられた。

マルチホップ認証とゲートウェイ統合

ユーザー→AIホスト→MCPクライアント→MCPサーバー→バックエンドAPIの多段境界では、各境界でトークンを再発行し aud 検証を挟むことで権限の横断的流用を防止します。

MCPを中心としたアーキテクチャでは認証境界が多段になる。「ユーザーがAIホストに与えたスコープ」をそのままバックエンドAPIへ流すと、バックエンドAPIはどのエージェントが実際に呼び出したのかを検証できず、権限超過を検知できない。

エンタープライズで採用されるゲートウェイ型の媒介パターンは次のように機能する。

MCPクライアントからのリクエストをゲートウェイが受信し、トークンの aud・スコープ・有効期限を検証する
検証済みクライアントIDを根拠として、バックエンドAPI向けの短期サブトークンをゲートウェイが新規発行する
サブトークンにはそのバックエンドAPI固有の aud と最小限のスコープのみを埋め込む
各ホップの呼び出しをゲートウェイがオーディットログに記録し、エージェントIDと要求内容の連鎖を追跡できるようにする

LLMゲートウェイ設計と組み合わせると、MCPトラフィックのレート制限・コスト計上・ポリシー適用を一元化できる。なお、実装上の最大の落とし穴は aud クレームの未検証だ。署名のみ確認して aud を検証しない実装はtoken replayを完全に許容する。checkResourceAllowed のような標準検証関数を使い aud が自サーバーURLに一致するかを必ず確認する。アクセストークンや client_secret はプロンプト文字列に含めず、ツール実装の内部でのみ扱う——LLMのコンテキストへの露出は機密漏洩に直結する。

参考

まとめ

MCPサーバーのOAuth 2.1認可設計は7要素で構成される。①Protected Resource Metadata（RFC 9728）の実装、②PKCE必須のAuthorization Code Flow、③Client ID Metadata Documents優先のクライアント登録、④Resource Indicators（RFC 8707）によるトークン束縛、⑤Step-Up Authorization Flowによるスコープの段階付与、⑥用途別フロー分離（ユーザーフロー vs Client Credentials M2M）、⑦ゲートウェイ型マルチホップ認証パターンだ。これらを正しく組み合わせることで、エージェントが正規のMCPサーバーにのみアクセスできる安全な認可基盤が完成する。

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

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