MCPのOAuth認証・認可｜リモートサーバーの権限設計

MCPのOAuth認証・認可では、接続主体を確認しただけで全機能を許可してはいけません。MCPサーバー宛てのトークンか、現在の操作に必要なscopeを持つか、利用者へ見せてよいTool・Resource・Promptかを要求ごとに判定します。認証成功を全機能の許可と扱わず、一覧表示、読み取り、実行、更新を分けることが権限設計の中心です。

リモートMCPの認証・認可を適用する境界を決める

認証は「誰またはどのクライアントか」を確かめる工程、認可は「その主体がこの要求を実行してよいか」を決める工程です。営業担当者Aが正しくログインしていても、管理者向けの`inventory_adjust` Toolを使えるとは限りません。要求の主体、対象MCPサーバー、操作名、引数に含まれる拠点、現在のscopeを組み合わせて判定します。

MCP 2026-07-28のAuthorization仕様はHTTPベースTransportの認可フローを定め、認可機能そのものはMCP実装で任意としています。ただしHTTPで認可を提供する場合はこの仕様へ従うべきであり、stdioでは同じフローを使わず環境から資格情報を取得する方針です^[1]。社内ネットワークだから無認証にするのではなく、保護対象があるリモートサービスはOAuth適用を原則とします。

適用外も明記します。公開情報だけを返す匿名MCP、開発者個人の端末で動くstdio、MCPサーバーから先の在庫API内部権限は、同じ認可表へ混ぜません。ただし上流APIの認証が別だからといって、受信トークンを転送してよいわけではありません。MCP境界と上流境界は資格情報も監査も分離します。

ログイン済み、MCP接続済み、Tool実行許可済みは三つの異なる状態です。画面と監査記録でも同じ言葉にまとめません。

四つの役割と必須要件を分離する

保護されたMCPサーバーはOAuth 2.1のResource Server、MCPクライアントはOAuth Clientとして振る舞います。Resource Ownerは通常、操作を委任する利用者です。Authorization Serverは利用者との対話、クライアントの確認、トークン発行を担当します。認可サーバーをMCPサーバーと同居させても別サービスにしても構いませんが、役割ごとの入力と責任は維持します。

通信路にも必須条件があります。公式仕様は、Streamable HTTPのサーバーが不正な`Origin`を受信した場合、403を返すよう求めています。ローカル実行時は全インターフェースではなくlocalhostへbindし、接続を適切に認証します^[5]。TLS終端がプロキシにある場合でも、MCPサーバーは信頼できる転送元、外部URL、`Origin`の評価方法を決めます。

本番へ進める最低要件は、HTTPS、保護対象メタデータ、認可サーバーメタデータ、登録済みクライアント、PKCE、`resource`、トークン検証、scope判定、監査ログ、失効手段です。いずれかが「後で対応」なら、公開Toolを読み取り一件へ制限しても本番扱いにしません。検証環境では実データを使わず、資格情報の有効期限を短く設定します。

認可サーバー発見とクライアント登録を固定する

MCPクライアントは、接続先URLから推測した認可エンドポイントへ直接トークンを取りに行きません。MCPサーバーがOAuth 2.0 Protected Resource Metadataを公開し、その`authorization_servers`に一つ以上の認可サーバーを示します。401応答の`WWW-Authenticate`に`resource_metadata` URLを載せる方法、またはwell-known URIで提供する方法が公式の発見経路です^[2]。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
  resource_metadata="https://mcp.corp.example/.well-known/oauth-protected-resource",
  scope="inventory.read"
{
  "resource": "https://mcp.corp.example/mcp",
  "authorization_servers": ["https://id.corp.example"]
}

上のドメインは想定例です。実装では外部から渡されたメタデータURLを無条件に取得せず、HTTPS、許可ホスト、リダイレクト回数、応答サイズ、タイムアウトを制限します。複数の認可サーバーが列挙された場合、クライアントは登録情報とトークンを発行者ごとに分け、一方の`client_id`やtokenを他方へ送らないようにします。

クライアント登録は三方式です。既存関係がある業務クライアントは事前登録します。未知のクライアントとの接続にはClient ID Metadata Documents、旧環境など特定要件にはDynamic Client Registrationを使えます。公式仕様は、利用可能なら事前登録を優先します。次にClient ID Metadata Documents、Dynamic Client Registrationを検討し、最後に利用者による手入力を使います^[3]。

登録台帳には、`client_id`、認可サーバー、所有部署、redirect URI、許可grant、初期scope、登録日、失効日、連絡先を残します。同じ表示名のクライアントでも`client_id`が異なれば別主体です。利用終了後24時間以内に登録を無効化するという想定SLAを置き、四半期ごとに実利用のない登録を抽出します。

OAuthの流れを八段階で実装する

実装順は、接続、発見、登録、認可要求、応答検証、トークン交換、MCP要求、scope追加の八段階です。順番を飛ばして固定トークンを設定欄へ貼り付ける方法は、発行者、対象、同意、期限を追跡しにくいため本番手順にしません。Authorization CodeではPKCEのverifierと`state`を要求ごとに生成し、認可応答と結び付けます。

1. MCPエンドポイントへ認証なしで接続し、401と`resource_metadata`を受け取る。
2. Protected Resource Metadataから認可サーバー候補を取得し、許可ポリシーで選ぶ。
3. 認可サーバーメタデータを検証し、登録済み`client_id`または登録方式を確定する。
4. PKCEのS256 challenge、`state`、必要最小限のscope、MCPサーバーを示す`resource`で認可要求を作る。
5. redirect後、保存した発行者、`iss`、`state`を比較し、不一致ならcodeを使わない。
6. token要求にも同じ`resource`とPKCE verifierを含め、tokenを安全な保管領域へ置く。
7. 各MCP HTTP要求の`Authorization`ヘッダーへBearer tokenを付け、URLクエリには入れない。
8. 403の`insufficient_scope`を受けた場合だけ、既存scopeとの和集合で再認可し、上限回数を超えたら停止する。

GET /authorize?
  response_type=code
  &client_id=https%3A%2F%2Fclient.corp.example%2Fmetadata.json
  &redirect_uri=https%3A%2F%2Fclient.corp.example%2Fcallback
  &code_challenge=<S256-challenge>
  &code_challenge_method=S256
  &state=<request-bound-random-value>
  &scope=inventory.read
  &resource=https%3A%2F%2Fmcp.corp.example%2Fmcp

このURLは要素説明用で、実際のホスト名や値ではありません。認可応答に`iss`がある場合は、事前に検証したメタデータのissuerと単純文字列比較し、大小文字変換や末尾スラッシュ除去で一致させません。メタデータが`authorization_response_iss_parameter_supported`をtrueと宣言したのに`iss`がない場合も拒否します。

クライアントがPKCE対応をメタデータで確認できない場合、フローを続けません。redirect URIは登録値と完全一致させ、認可code、access token、refresh tokenをアプリの通常ログへ書かないようフィルターを試験します。利用者が同意画面で拒否した場合は業務エラーへ変換せず、「権限付与なし」と表示してTool実行を終了します。

resource・audience・トークン横流し禁止を検証する

`resource`は、クライアントがどのMCPサーバー向けのtokenを求めているかを示します。認可要求とtoken要求の両方に含め、schemeを含むMCPサーバーの正規URIを使います。MCPサーバーはtokenの署名や期限だけでなく、自分が意図されたaudienceであることを検証します。別の社内API向けtokenが有効でも、在庫MCP向けでなければ401で拒否します。

公式のAuthorization Security Considerationsは、`resource`の送信、MCPサーバー側の対象検証、token passthrough禁止を明示しています。また、tokenをクライアントやサーバーのログ・キャッシュから盗まれた場合、正規要求に見えるアクセスへ使われるため、安全な保管と短命なaccess tokenが重要です^[4]。

MCP Client
  -- token A (aud: inventory-mcp) --> Inventory MCP Server
Inventory MCP Server
  -- token B (aud: inventory-api) --> Inventory API
禁止:
Inventory MCP Server
  -- token Aをそのまま転送 --X--> Inventory API

MCPサーバーが上流APIへ接続するときは、上流向けの別tokenを取得します。利用者委任が必要なら、組織で承認したtoken exchangeなどの方式を別設計し、「受信Bearerをヘッダーごと転送する」実装にはしません。上流tokenのscopeはMCP側scopeから機械的に拡大せず、例えば`inventory.write`を持つ利用者でも、対象拠点が大阪なら東京拠点への上流権限を与えません。

監査ログにtoken本体は残しません。tokenを識別する必要があれば、復元不能なハッシュまたは認可サーバーが発行した安全な識別子を使います。tokenが一度でもアプリログ、エラー本文、Tool結果へ現れたら、該当tokenと関連refresh tokenを失効させ、ログ保管先を調査し、再発防止試験が終わるまで更新系Toolを停止します。

Tools・Resources・Promptsへ権限を割り当てる

MCP権限は「サーバーへ接続できるか」だけでは粗すぎます。Toolsはモデルが選択して外部処理を実行でき、公式仕様も人が呼び出しを拒否できるUIを推奨しています。さらに`tools/list`の結果は、要求に付いた認可に応じて変えてよいと定められています^[6]。権限外のToolは`tools/call`で拒否するだけでなく、一覧からも除き、名称や説明から機密業務が漏れないようにします。

ResourcesはURIで識別され、ホストアプリケーションが文脈へ取り込む情報です。`resources/list`も認可に応じて返す集合を変えられます^[7]。例えば`inventory://tokyo/current`は東京担当者へ、全拠点のCSVは本部へ限定します。URIを知っている利用者が`resources/read`を直接送っても、一覧と同じ条件をサーバー側で再判定します。

Promptsは利用者が明示的に選ぶテンプレートで、`prompts/list`の返却集合も要求の認可で絞れます^[8]。月次役員報告Promptに非公開の評価基準が含まれるなら、一般営業の一覧へ出しません。Promptの取得を許可しても、Prompt内から呼ばれるToolの実行権限が自動で付くわけではなく、Tool要求時に改めて判定します。

scope名だけで行・列の権限を表現し切れない場合は、tokenの主体情報と社内ディレクトリの属性を使ってポリシーを評価します。クライアントが送る`site_id`を信用せず、許可拠点との交差をサーバー側で取ります。結果をモデルへ返す直前にも、個人情報、秘密列、最大件数を検査し、入力時と出力時の二段階で権限逸脱を防ぎます。

401・403・再認可・失敗例を区別する

tokenがない、期限切れ、署名不正、audience不一致なら401です。tokenは有効だが現在の操作にscopeまたは権限が足りない場合は403を返します。Authorization仕様は、scope不足時に403を返す例を示しています。`WWW-Authenticate`には`error=”insufficient_scope”`、必要scope、`resource_metadata`を含めます。クライアントは不足scopeと既存scopeの和集合で再認可できますが、再試行上限を設けます。

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
  scope="inventory.write",
  resource_metadata="https://mcp.corp.example/.well-known/oauth-protected-resource",
  error_description="Inventory adjustment permission required"

失敗例1は、403を受けるたびにscopeを一つずつ追加する実装です。誤設定や悪意ある要求で同意画面が繰り返され、最終的に過大権限を得る恐れがあります。サーバーは現在の操作に必要なscopeを一回のchallengeへまとめ、クライアントは同じresource・operationに対する段階追加を最大二回という想定上限で止めます。

失敗例2は、401をログイン画面へ無限リダイレクトすることです。audienceが違うtokenは再ログインしても直らない場合があります。クライアントは発見URL、issuer、resource、`client_id`、redirect URIの組み合わせを表示し、同一条件で二回失敗したら恒久エラーとして利用者へ戻します。token本体やcodeは診断画面へ出しません。

失敗例3は、更新Toolの403を一般的なToolエラーに変換し、モデルへ再試行させることです。権限拒否は業務処理の一時失敗ではありません。モデルへは「権限がないため実行していない」という構造化結果だけを返し、別Toolへの迂回やscope追加を自動決定させません。利用者が明示的に権限申請を選んだ場合だけ再認可へ進みます。

社内ルールと責任分担へ落とし込む

仕様準拠だけでは、誰がscopeを作り、誰がToolへ割り当て、誰が事故時に止めるかは決まりません。業務所有者は操作とデータ範囲を定義し、ID基盤担当は発見・登録・token発行を管理し、MCP所有者は要求ごとの検証と一覧絞り込みを実装します。セキュリティ担当は脅威モデルと例外を審査し、監査担当は記録から一件を再現します。

監査ログには、時刻、要求ID、クライアントID、主体識別子、issuer、resource、Tool・Resource・Prompt名、要求scope、判定規則IDを残します。さらに、許可または拒否、HTTP状態、対象拠点、結果件数を記録します。入力本文は最小限にし、個人情報やtokenを保存しません。更新Toolでは変更前後の業務IDと利用者の確認結果を追加します。

保持期間は法令を推測せず、自社の契約、事故対応、監査要件から決定します。想定例として操作ログを13カ月、認可codeやtoken本文は0日、クライアント登録変更履歴を24カ月と設定できます。期間を決める際は、削除ジョブが実際に動くこと、バックアップからも期限後に消えること、監査担当が必要な追跡を行えることを確認します。

月次運用では、未使用クライアント、過大scope、期限切れ例外、403急増、同一主体の拠点横断要求を確認します。四半期ごとに一件の許可と一件の拒否を選び、登録からTool結果まで追跡します。担当者が異動した、業務所有者が不明、監査ログの欠損が一日を超えた場合は、新規クライアント登録を停止します。

32件の受入試験で越権を検出する

受入試験は、正常8件、token不正8件、scope・属性不正8件、発見・登録4件、停止・復旧4件の計32件という想定構成です。正常系だけを通すと、署名は検証していてもaudienceを見ていない、一覧は絞るが直接呼び出しを許す、といった欠陥を見逃します。各試験へ期待HTTP状態、期待JSON-RPC結果、監査イベントを設定します。

Tools、Resources、Promptsは、一覧と直接操作を対にして試験します。権限なしの`tools/list`に更新Toolがないことに加え、名前を知って`tools/call`しても403になることを確認します。Resource URIの列挙・直接read、Prompt名の列挙・直接getも同様です。三種類で少なくとも各二件の越権負例を用意します。

越権拒否率 = 正しく拒否した越権試験数 ÷ 越権試験総数 × 100
一覧秘匿率 = 一覧に出なかった禁止対象数 ÷ 禁止対象総数 × 100
失効反映時間 = 失効確定時刻から最初の401までの秒数
監査完全率 = 必須項目がそろった試験ログ数 ÷ 全32件 × 100

想定合格線は、越権拒否率100%、一覧秘匿率100%、失効反映時間60秒以内、監査完全率100%、token本文の記録0件です。32件を二つのクライアント版で行うなら母数は64件になります。合格線は業務の復旧目標に合わせて試験前に承認し、失敗後に緩めません。

結果にはMCP仕様版、クライアント版、サーバー版、認可サーバー設定版、鍵ID、ポリシー版を添えます。鍵更新やscope変更の後は関連区分だけでなく、正常系と他resource tokenも再実行します。一件でも上流更新が発生した越権試験は重大事故候補として扱い、検証環境のデータを初期化して原因を調査します。

停止・例外・見直しの条件を先に承認する

即時停止条件の第一群は、tokenまたは認可codeの露出、audience不一致tokenの受理、権限外Toolの実行です。第二群は、他拠点Resourceの返却、未承認Promptの表示、不正Originの許可、監査不能な更新です。検出した場合、更新系Toolを全停止し、影響tokenとクライアント登録を無効化します。読み取り機能も、影響範囲が分かるまで閉じます。

例外は、対象クライアント、対象scope、理由、代替統制、開始日、終了日、監視担当、取消手順をそろえた場合だけ審査します。「旧製品だから」「検証を急ぐから」だけでは承認しません。Dynamic Client Registrationを一時許可するなら、登録上限、許可redirect URI、ネットワーク範囲、最長30日という想定期限を設定し、期限後は自動で拒否します。

見直しトリガーは、MCP仕様版変更、認可サーバー変更、クライアント追加、redirect URI変更、新しいTool・Resource・Promptです。scope体系変更、データ区分変更、組織再編、鍵更新、重大な401/403増加も対象にします。月次件数が平常値の三倍になった場合など、数値トリガーも定義します。季節要因がある業務では前年同月と比べます。

認可が向かないのではなく、現在の運用体制ではリモートMCPを提供すべきでないケースがあります。ID基盤の所有者が不明、失効を一営業日以内に反映できない、利用者別ログを保存できない、scopeの承認部署がない場合です。この状態ではstdioの限定検証またはMCPを使わない既存画面へ戻し、共有リモートサービスの利用者追加を止めます。

MCP認可で判断に迷う点

社内SSOへログイン済みならMCP用OAuthは省けますか？

SSOセッションだけでは、どのMCPサーバー向けのtokenか、どのクライアントが委任を受けたか、必要scopeは何かを示せません。既存ID基盤を認可サーバーとして再利用しても、Protected Resource Metadata、client registration、resource、audience、scopeの確認は必要です。

Toolごとにscopeを一つ作るべきですか？

必ずしも一対一にしません。安定した業務能力で`inventory.read`と`inventory.write`を分け、拠点や組織は属性ポリシーで判定できます。ただし一つの`mcp.full`に全操作を集めると最小権限を保てません。更新、外部送信、削除は読み取りと分離します。

権限外Toolを一覧に表示し、実行時だけ403にしてもよいですか？

仕様上、一覧は認可に応じて変えられます。機密の操作名や説明を見せる必要がないなら一覧から除外し、直接呼び出しも403にします。UI上の非表示だけでは、名前を知るクライアントから呼べるためサーバー側判定が必須です。

refresh tokenを必ず発行すれば再ログインを減らせますか？

クライアントはrefresh tokenが発行されると仮定できません。必要性、保管能力、失効、回転を評価し、認可サーバーの裁量に従います。短時間の管理操作ならaccess tokenだけとし、利便性のために長期資格情報を増やさない選択もあります。

次の行動として権限設計レビューの成果物をそろえる

次の行動：MCPサービス所有者は、四役の構成図、Protected Resource Metadata、認可サーバーメタデータ、クライアント登録台帳、redirect URI、scope辞書を提出します。併せて、Tools・Resources・Promptsの権限表、token検証項目、401/403例、32件の試験結果をそろえます。監査ログ例、失効実測、停止・再開表、期限付き例外一覧も提出対象です。秘密値は削除し、設定の版と所有者を添えます。

承認条件の第一群は、他resource tokenと期限切れtokenが401、scope不足と担当外拠点が403になることです。第二群は、禁止対象が三一覧に現れず、直接操作も拒否されることです。受信tokenが上流へ転送されないこと、失効が合意時間内に反映されること、利用者が更新Toolを拒否できることも確認します。一項目でも証拠がない場合は「認証済み」を「本番認可済み」と扱わず、読み取り限定の検証へ戻します。

最終欄には、サービスを止められる担当者と連絡方法を24時間帯別に記載します。重大条件を検出した際に会議を待たず停止できる権限、停止後の利用部門への通知、再開承認者を決めます。これによりOAuthの設定確認だけで終わらず、越権を発見してから被害を広げない運用まで一つの成果物として確認できます。

参考文献・出典

1. Model Context Protocol公式仕様「Authorization」（MCPのOAuth認証・認可フロー、Protocol Revision 2026-07-28、2026年7月30日参照）
2. Model Context Protocol「Authorization Server Discovery」（Protocol Revision 2026-07-28、2026年7月30日参照）
3. Model Context Protocol「Client Registration」（Protocol Revision 2026-07-28、2026年7月30日参照）
4. Model Context Protocol「Authorization Security Considerations」（MCP認可の権限設計と安全上の考慮事項、Protocol Revision 2026-07-28、2026年7月30日参照）
5. Model Context Protocol「Streamable HTTP」（Protocol Revision 2026-07-28、2026年7月30日参照）
6. Model Context Protocol「Tools」（Protocol Revision 2026-07-28、2026年7月30日参照）
7. Model Context Protocol「Resources」（Protocol Revision 2026-07-28、2026年7月30日参照）
8. Model Context Protocol「Prompts」（Protocol Revision 2026-07-28、2026年7月30日参照）

記事中のドメイン、件数、保持期間、再試行回数、SLAは設計方法を示す想定例です。実在する接続先や実績値ではありません。採用時は自社のID基盤、契約、情報分類、復旧目標へ置き換えてください。