MCP 認証・権限管理の設計ベストプラクティス

複数の導入事例や仕様レビューを踏まえると、stdio と remote HTTP を切り替える際に、401 の challenge や同意フロー、トークンの audience 検証でつまずくポイントが共通して報告されることが少なくありません。
MCP の認可設計は単に OAuth を入れれば済む話ではなく、接続形態ごとの脅威モデルを踏まえて設計する必要があります。
stdio は API キーや Device Flow、remote HTTP は OAuth 2.1 を軸に設計するのが運用上の整理として有効です。

MCPとは何か

MCP は、LLM から外部ツール、API、ファイルシステムへ接続するための標準化された規格です。
単なる「プラグインの差し替え口」ではなく、モデルがどの道具に触れ、どのデータに到達できるかを横断的に束ねる層だと捉えたほうが実態に近いです。
ここで認証や権限の設計を誤ると、個別 API の設定ミスよりも影響範囲が広がります。
ひとつの MCP サーバーが社内ドキュメント、チケット、ソースコード、SaaS 上の業務データをまたいで扱えるため、入口の設計ミスがそのまま組織内の露出面を広げるからです。

この前提が、2025 年の仕様更新でさらに明瞭になりました。
2025-03-26 版で OAuth 2.1 ベースの認可フローが大きく前進し、2025-06-18 版のMCP Authorization Specification (2025-06-18)では、MCP サーバーが OAuth の Resource Server としてトークンを受け入れ、検証する立場だと整理されています。
加えて、クライアントは RFC 8707 の resource パラメータで対象 MCP サーバーを示し、サーバーは RFC 9728 の Protected Resource Metadata を通じて認可サーバーの情報を返す流れが基本線になりました。
401 Unauthorized と WWW-Authenticate ヘッダから認可情報を発見させる構成も、この文脈で理解すると腹落ちします。

実装では、接続形態によって選ぶ認証方式が変わります。
CursorやClaude Codeで触っていると、この分岐を曖昧にした瞬間に設計が崩れます。
ローカルの stdio 型 MCP なら、APIキーや Device Flow のようなローカル向け手段が現実的です。
端末上の開発補助ツールや一時的な PoC では、環境変数に入れた APIキーで最低限の動作確認を進める場面もあります。
一方、remote HTTP の MCP では、ユーザー同意、短命トークン、スコープ制御、失効処理まで含めて扱える OAuth 2.1 系のフローが中核になります。
推奨の中心は Authorization Code + PKCE です。
ブラウザで同意を取り、クライアント側は PKCE で認可コード横取りを防ぎ、サーバー側は受け取ったアクセストークンの audience と scope を検証する、という形が最も筋が通っています。

短命トークン前提の設計にしておく意味も大きいです。
Bearer JWT の TTL を 5 分以下で切る運用では、8 時間の作業セッション中に最大で約 96 回の更新が発生しうる計算になります。
人手で回す前提は最初から成り立たず、クライアントの自動更新、失効時の再チャレンジ、監査ログまで含めて設計しないと運用が持ちません。
MCP は接続規格ですが、実務では認証基盤の設計力がそのまま露出します。

認証と認可の境界

MCP の議論で混線しやすいのが、認証と認可をひとまとめにしてしまうことです。
認証は「その主体が誰か、本物か」を確かめる行為で、認可は「その主体が何をしてよいか」を決める行為です。
ユーザーがGitHubでログインできたとしても、それだけでは「この MCP サーバー経由で特定リポジトリを読める」「経費データには触れられない」といった境界は決まりません。
ここを分けて設計しないと、ログイン成功の瞬間に広すぎる権限が付いてしまいます。

APIキーはこの境界を曖昧にしやすい代表例です。
キーを持っている主体が誰なのかが粗く、同じキーを複数人や複数クライアントで共有すると、実質的に「誰が使ったか」と「何に同意したか」が分離できません。
ローカル stdio で、自分だけが使う補助ツールに限定し、権限も狭く切っているなら実務上は成立します。
たとえばローカルのファイル参照専用、読み取り専用の社内検索、個人アカウント配下の開発用 API といったケースです。
このときも APIキーはシークレットストアや環境変数に置き、長寿命・共有・高権限の三点セットを避けるのが前提になります。

remote HTTP で複数ユーザーが使う MCP は、OAuth 2.1 の Authorization Code + PKCE を基準に考えるほうが自然です。
MCP クライアントは public client として動く場面が多く、クライアントシークレットに依存できないため、PKCE を入れた認可コードフローが相性のよい選択になります。
ブラウザでユーザー本人の同意を取り、スコープを明示し、発行されたトークンをサーバー側で検証する。
MCP 仕様の流れとも一致します。
IdP 側は現実には OAuth 2.0 ベースの実装が多いものの、MCP 文脈では OAuth 2.1 的な要件が強く求められるため、resource、audience、PKCE、同意画面、失効処理が噛み合うかどうかが選定の分かれ目です。

Device Flow は、ブラウザ遷移が前提にしづらい CLI、ヘッドレス端末、ローカル常駐プロセスで有力です。
非対話系といっても、ここで言うのは「バックグラウンドジョブだから何でも無人でよい」という意味ではありません。
人がその場でコードを入力して端末認可を終える Device Flow と、完全な機械間連携は分けて考える必要があります。
前者は stdio 型のローカル利用や CLI ツールに向きます。
後者はサービスアカウントやワークロード ID の設計に寄りますが、少なくとも「ユーザーが操作する remote MCP に高権限 APIキーを埋め込む」代替にはなりません。

権限モデルも、MCP では一段細かく見たほうが事故を減らせます。
RBAC は「開発者」「監査担当」といった役割単位でまとめるには扱いやすく、ABAC はデータ分類、所属部署、時間帯、環境、リクエスト元といった属性を加味して制御できます。
社内文書や顧客データを扱う MCP では、RBAC だけだと「開発者だから全部読める」に寄りがちです。
そこに ABAC を重ねて「本番顧客データは担当部署かつ承認済みセッションだけ」「個人情報は読み取り専用ツールからのみ」といった境界を置くと、MCP の横断性に引きずられにくくなります。

公開MCP/高権限トークンの具体的リスク

公開された remote MCP サーバーを、単一の APIキーや長寿命の高権限トークンで回す構成は、短期のデモでは動いても本番運用では破綻しやすいのが利点です。
問題は漏えいそのものだけではありません。
権限が広すぎる、利用主体を識別できない、同意と監査が追えない、失効時に影響が広すぎる、という複数の欠点が同時に出ます。
MCP はツール呼び出しの入口が統一されるので、ひとつのトークンで触れる範囲が広いほど、事故の半径もそのまま広がります。

公開テスト用に立てたリモート MCP を、一時期 APIキー単体で運用していたことがあります。
立ち上げ直後はそのほうが早く、クライアント接続の確認も簡単でした。
ただ、ログを見返した段階で限界がはっきりしました。
だれが、どのスコープに、どのタイミングで同意したのかを結びつけて追えず、操作主体の説明責任が立ちませんでした。
アクセスが成功していることは分かっても、「この利用は正当な許可の結果か」を後から示せないのです。
その時点で APIキー運用を引っ張る意味がなくなり、短期間で OAuth 化を決めました。
認証方式を変えたというより、監査可能な形に戻した感覚に近かったです。

たとえば社内ナレッジ、チケット管理、コードリポジトリをまとめて扱う公開 MCP を想像すると、単一トークン運用の危うさが見えます。
読み取り専用のつもりで始めても、バックエンド API 側に書き込み権限が残っていれば、モデル経由でチケット更新や設定変更まで到達します。
監査ログにユーザー単位の同意記録がなければ、誤操作でも不正利用でも切り分けがつきません。
漏えいしたトークンを止めるときも、そのトークンにぶら下がる正当な利用まで一斉に止まります。
影響範囲を利用者単位、クライアント単位、スコープ単位に切れないからです。

MCP サーバーが受け取ったアクセストークンを、そのまま下流サービスへ通過させる設計にも警戒が必要です。
MCP サーバーは Resource Server としてトークンを受け入れ、検証し、自分の責務の中で扱うべきで、下流への無造作な透過は責任境界をぼかします。
audience のずれ、想定外スコープの伝播、下流側ログとの突合不能が起きると、障害解析も監査も一気に難しくなります。

ただし、クライアント実装（例: Cursor や Claude Code）については、RFC 8707 の resource パラメータや同意履歴の出力をどこまで明示的にサポートしているかは、公式ドキュメントに差があります。
特定クライアントの挙動を断定する前に、当該クライアントの最新ドキュメントやリリースノートを確認し、クライアント間で実装差がある前提でサーバー側の堅牢化を進めてください。

まず整理したい前提：stdioとremote HTTPでベストプラクティスは変わる

認証方式を選ぶ前に、まず transport の違いを切り分けておくと混乱が減ります。
MCP は同じ「サーバー接続」でも、ローカルで子プロセスとして動かす stdio と、ネットワーク越しに公開する remote HTTP では前提となる脅威モデルが大きく異なります。
この切り分けを曖昧にしたまま「APIキーでもOAuthでもどちらでもよい」と考えると、実装は通っても管理が破綻します。
実際にCursorやClaude CodeでローカルMCPとリモートMCPを行き来していると、接続方法の違いというより、誰に対して何を許可し、どう取り消すかの考え方そのものが変わると感じます。

stdioの現実解

stdio のMCPサーバーは、ローカルマシン上でクライアントから子プロセスとして起動される構成が中心です。
この場合、現実的な第一候補は APIキーを環境変数やOSのシークレット保管に置くやり方です。
前のセクションでも触れた通り、秘密の配布域がユーザー自身の端末に閉じるので、公開Webサービスほど大きな配布リスクを抱えません。
ローカルの filesystem 系MCPを試したときも、まず APIキーを環境変数に入れて動かす構成が最短でした。
接続確認までの距離が短く、PoC の立ち上がりも速かったです。

ただし、ここでの「使える」は「雑に扱ってよい」という意味ではありません。
stdio でも APIキーは最小権限で発行し、用途ごとに分け、ローテーション前提で扱う必要があります。
1つのキーを複数ツールで共用すると、どのクライアントから何が実行されたか追いづらくなります。
ローカル用途であっても、管理者権限相当の長寿命キーを固定する構成は避けたいところです。

ブラウザを前提にしにくいCLI寄りの操作では、Device Flow も実務に乗りやすい選択です。
別ブラウザや別デバイスでコード承認できるので、ターミナル中心の導線と噛み合います。
特に、ローカルで動かす補助ツールや、ユーザーがエディタ内ではなく端末から認証を完結させたい場面では、Authorization Code フローより収まりがよいことがあります。
stdio では「APIキーか Device Flow か」で考えると、設計のブレが減ります。

remote HTTPの前提

remote HTTP のMCPは、インターネット越し、あるいは社内ネットワーク越しに複数のユーザーやクライアントから到達される前提になります。
ここでは APIキー常用より、OAuth 2.1 の Authorization Code + PKCE を軸に据えるほうが筋が通ります。
ユーザーごとの同意、短命アクセストークン、スコープ制御、失効、監査のどれもが扱いやすくなるからです。
MCP の現行仕様でも、MCPサーバーが保護リソースとして振る舞い、認可情報をクライアントに案内する流れが整理されています。
MCP Authorization Specification (2025-06-18)では、サーバーが OAuth 2.1 の Resource Server としてトークンを受け入れて検証する立場が明確にされています。

remote HTTP で押さえたいのは、OAuth を「ログイン機能」ではなく「権限の受け渡しと失効の仕組み」として見ることです。
たとえば GitHub 連携の remote MCP を APIキー中心で組むと、接続そのものは早くても、誰がどのリポジトリ権限に同意したかを追いにくくなります。
筆者もこの構成を PKCE 対応に切り替えた途端、同意履歴と失効が運用の言葉で語れるようになった感覚がありました。
接続可否の話から、利用者単位の管理に話題が移るんですよね。

仕様面でも、remote MCP は「401を返して終わり」ではありません。
WWW-Authenticate による challenge、Protected Resource Metadata による認可サーバー情報の発見、そして対象サーバーを示す resource パラメータの扱いがセットです。
Understanding Authorization in 。
実装では IdP との相性や DCR の現実的な壁が出ますが、公開運用の土台が OAuth 2.1 中心であること自体は揺れません。

APIキーを remote HTTP でまったく使えないわけではありません。
初期の検証や限定公開では残る場面があります。
ただ、そのまま本番運用へ延長する発想は危険です。
remote で APIキーを採るなら、OAuth への移行計画を最初から持っておくべきです。
remote は「まず繋げる」より、「あとで誰単位で止められるか」が効いてきます。

ブラウザ同意フローとクライアントUIの注意点

Authorization Code + PKCE を採ると、多くのMCPクライアントではブラウザ同意フローが登場します。
ユーザーはクライアントから remote MCP に接続しようとしたタイミングでブラウザへ移り、認可サーバー上でログインし、要求されたスコープに同意し、完了後にクライアントへ戻る、という流れです。
ネイティブアプリやエディタ連携では、この戻り先にローカルコールバックやカスタムURIスキームを使う構成がよく採られます。
実際に使ってみると、認証はブラウザ、作業継続はエディタ、という分担になるので、利用者の理解もしやすくなります。

ここで注意したいのは、MCPクライアントのUIが認可サーバーそのものではないことです。
ツール一覧や接続設定、ログ表示はCursorやClaude CodeやVisual Studio Code側の役割ですが、同意画面の主体は OAuth の認可サーバーです。
つまり、クライアントUIで見える「接続済み」「再認証が必要」「認証エラー」と、ブラウザで見える「どの権限に同意したか」は分けて考える必要があります。
MCPクライアント側で接続ログを追えても、同意履歴の管理主体まで同じとは限りません。

もう1つ見落としやすいのが、ブラウザ同意フローは UX のためだけでなく、ユーザーの意思を明示的に残す場所でもある点です。
APIキーを手入力して終わる導線では、この「誰がどの範囲を許可したか」が薄くなりがちです。
ブラウザ同意を挟むと、少なくとも利用者単位での認可と失効の筋道が立ちます。
remote HTTP ではこの差がそのまま運用差になります。
ローカルでは導入速度を優先し、公開では同意と失効を優先する。
この整理がついていると、認証方式の選択で迷いにくくなります。

2025-06-18時点のMCP認可フローの要点

401とWWW-Authenticateの役割

2025-06-18時点のMCP Authorization Specification (2025-06-18)は、MCPサーバーがOAuth 2.1のResource Serverとして振る舞う点を明確にしています。
MCPサーバーはアクセストークンを受け取り、検証し、許可された操作だけを通します。
トークンを発行する主体はAuthorization Server（AS）であり、MCPサーバー自身が勝手に発行役へ回るわけではありません。
この役割分担が曖昧だと、認可まわりの責務が一気に崩れます。

未認証のクライアントがMCPサーバーへ到達したとき、応答は単なる失敗通知ではなく401 Unauthorizedが基点になります。
ここでMCPサーバーはWWW-Authenticate: Bearer ...を返し、クライアントに「Bearerトークンが必要であること」と「どこから認可情報を見つけるか」を伝えます。
MCPではこのchallengeの中にresource_metadataを含め、保護対象リソースのメタデータ位置を案内する流れが中核です。
つまり401は拒否で終わるコードではなく、認可フローの入口として機能します。

この挙動は、WWW-Authenticate を展開して resource_metadata を確認すると理解しやすくなります。
最初に 401 が返ってきた時点では情報が限られますが、resource_metadata を辿ることでどの AS を使う設計かが分かる場合が多いです。
remote MCP で詰まる典型は、challenge を読まずに「トークンを付ければ通る」と思い込む点にあります。

PRM（RFC 9728）とresource_metadata

resource_metadataで指される先にあるのが、RFC 9728のProtected Resource Metadata（PRM）です。
これは保護リソースが、自分に対する認可の手掛かりを機械可読で公開するための仕様で、MCPではクライアントがASを発見するための土台になります。
このdiscoveryをchallengeと組み合わせる流れが整理されています。
PRM（RFC 9728）で特に注目すべき項目は authorization_servers です。
ここには、その MCP サーバー向けのアクセストークンをどの AS から取得すべきかが並びます。
クライアントは resource_metadata から PRM を取得して authorization_servers を参照し、認可先を決めるという流れが仕様上の基本です。

ここを読むと、MCPサーバーは「認可を提供するサービス」ではなく「認可済みアクセスを受ける保護リソース」だという輪郭がはっきりします。
たとえばCursorやClaude CodeのようなMCPクライアントから見ると、最初に知るべきなのはログイン画面のURLではなく、そのMCPサーバーが公開しているPRMです。
認可の入口をASの画面から考えるのではなく、保護リソースのメタデータから考える。
この順番の違いが、MCPの仕様理解では効いてきます。

Understanding Authorization in MCP - Model Context Protocol

Learn how to implement secure authorization for MCP servers using OAuth 2.1 to protect sensitive resources and operation

modelcontextprotocol.io

RFC 8707 resourceとaudience検証

トークン取得時の論点として外せないのが、RFC 8707のresource parameterです。
クライアントはASに対してトークンを要求するとき、resourceパラメータで「どの保護リソース向けのトークンが欲しいか」を明示します。
MCPでは、この対象がMCPサーバーそのものです。
ここが曖昧なまま「とりあえずBearerを発行してもらう」形にすると、別のAPI向けトークンや、対象が広すぎるトークンが混ざりやすくなります。

MCPサーバー側の検証も、署名が通るかどうかだけでは足りません。
少なくともexp、iat、nbfのような時刻系クレーム、有効な発行者を示すiss、そのサーバー向けであることを示すaudience検証、要求された操作に対して十分なスコープ、そして失効状態まで見て初めて受理できます。
特にaudienceは、RFC 8707のresourceに対応する関門です。
対象MCPサーバーと一致しないaudを持つトークンは拒否されます。

この点もMCP Inspectorで試したときに挙動が分かりやすく出ました。
WWW-Authenticateからresource_metadataを辿ってASを特定できても、トークン要求でresourceを付けずに進めると、取得できたように見えるトークンがMCPサーバーで弾かれます。
原因を追うとaudience不一致でした。
つまり、接続先を知ることと、その接続先を名指ししたトークンを取ることは別の段階です。
remote MCPで「認証は通ったのに使えない」という症状の中には、このresource不足が混ざっています。

トークンパススルー禁止の理由

MCPサーバーが受け取ったアクセストークンを、そのまま下流サービスへ流してはいけないという点も見逃せません。
いわゆるトークンパススルー禁止です。
MCPサーバーはResource Serverとして自分宛てトークンを検証して利用可否を判断する立場であり、受領したトークンを別サービスへの通行証として横流しする立場ではありません。

理由は単純で、アクセストークンのaudは本来そのMCPサーバー、つまり特定の保護リソースに結び付いているからです。
下流のAPIや別マイクロサービスは別の保護リソースですから、同じトークンで到達できる設計にするとaudience境界が壊れます。
すると、利用者がMCPサーバーにだけ与えたつもりの権限が、別の内部APIまで広がりかねません。
OAuthのスコープ設計や失効の意味も薄れます。

実装上は、MCPサーバーが必要に応じて下流向けに別トークンを取得する、あるいはサーバー間認証を分離する、という構成に寄せることになります。
受け取ったユーザートークンをそのまま転送すると、どの境界で誰の権限を評価したのかが曖昧になります。
MCPの認可フローは、401 UnauthorizedからWWW-Authenticate、resource_metadata、PRM、authorization_servers、RFC 8707のresource、そしてaudience検証までを一直線につなげることで成立します。
パススルーはその線を途中で折ってしまうので、仕様に沿った設計から外れていきます。

MCPの認証方式3パターンと使い分け

APIキー

APIキーは、MCPをまず動かす段階ではいちばん手早い方式です。
特にローカルのstdio接続では、クライアントとサーバーの境界が比較的閉じていて、環境変数やシークレットストアでキーを渡すだけで成立する場面が多く、小規模なPoCには向いています。
CursorやClaude Codeで手元の補助ツールをつなぐだけなら、最初の一歩としては現実的です。

ただし、運用を続けるほど弱点が目立ちます。
APIキーは「そのキーを知っている人」がそのまま利用者になってしまうので、共有が始まると誰が何を実行したのかを追いにくくなります。
キーが長寿命のまま残りやすく、退職者や一時参加メンバーのアクセス整理でも手間が増えます。
権限も「このキーに何を許すか」という単位になりがちで、ユーザーごとの差を表現しにくい構造です。

実際、私も小規模PoCではAPIキーで回していました。
最初は数人だけだったので問題になりませんでしたが、招待メンバーが増えるにつれて、閲覧だけでよい人と更新権限が必要な人を分ける設計が苦しくなりました。
キーを分けても結局は共有運用が残り、「誰に何を渡しているのか」が見えづらいままでした。
あとからPKCEベースの認可へ移したとき、ユーザー単位で権限と同意が結びついたことで、その整理が一気に進みました。

そのためAPIキーは、閉じたローカル用途、短期PoC、stdio中心に絞って考えるのが無難です。
remote HTTPのMCPサーバーを複数人で使う段階に入ったら、APIキー中心のまま引っ張るより、早めにOAuth系へ寄せたほうが後工程の摩擦が少なくなります。

Auth Code + PKCE

remote HTTPでMCPを公開するなら、第一候補はOAuth 2.1系のAuthorization Code + PKCEです。
MCPの認可仕様でも、401 challengeからresource_metadata、PRM、認可サーバーの発見へ進む流れが前提になっており、その先でユーザー同意とトークン発行を扱う構成と相性がよくなっています。
Model Context Protocolの『Authorization仕様』を読むと、保護リソースとしてのMCPサーバーと、認可を担うASを分けて考える設計が明確です。

PKCEが効くのは、MCPクライアントの多くがパブリッククライアントとして振る舞うからです。
RFC 7636で定義されたcode_verifierとcode_challengeを使うことで、認可コードを横取りされてもトークン交換を成立させにくくできます。
ブラウザに飛ばして同意を取り、短命のアクセストークンを発行し、必要ならASポリシーに沿ってリフレッシュトークンを扱う。
この流れなら、スコープ制御、失効、監査の各要素を同じ枠組みで扱えます。

MCPで特に効くのは、誰の権限で、どのMCPサーバーに、何を許したかを分解できる点です。
APIキー運用では「接続できるかどうか」で終わりがちですが、PKCEを使う構成ではユーザー同意画面、スコープ、トークン失効をつなげて扱えます。
前述の体験でも、メンバーが増えてからはこの差が効きました。
認証の成否だけでなく、編集権限を持つユーザーと閲覧だけのユーザーを分けて把握できるようになり、運用上の会話が技術寄りの暗黙知ではなく、権限設計の話に置き換わりました。

トークンTTLは認可サーバー側のポリシーに従いますが、Bearer JWTは短命に寄せるのが定石です。
現場では5分程度以下の設定を見かけます。
ここで手動更新を前提にすると長時間セッションで破綻するので、クライアント側は自動リフレッシュを前提に組むことになります。
3時間ほど連続でCursorやVS CodeからMCPを叩く使い方でも、最初のブラウザ認可のあと継続利用しやすいのはこのためです。

加えて、MCPではresourceパラメータやaudience検証まで揃ってはじめて安全側に寄ります。
『Understanding Authorization in MCP』でも、認可要求と保護リソースの結び付けが実装上の焦点として整理されています。
remote HTTPで正式運用に入るなら、Authorization Code + PKCEを基準線に据えるのが自然です。

Authorization - Model Context Protocol

modelcontextprotocol.io

Device Flow

Device Flowは、ローカルCLIや画面のない環境で効きます。
たとえばターミナル中心のMCPクライアントや、ブラウザ埋め込みを持たない実装では、端末側にクライアントシークレットを置かずに認可を進める必要があります。
そのとき、ユーザーに別デバイスやブラウザで認証してもらい、CLI側はデバイスコードで待ち合わせる方式が収まりのよい選択になります。

この方式の強みは、非対話に近い見た目でも、裏ではユーザー同意を維持できることです。
完全な無人ジョブ向けというより、「操作主体はユーザーだが、その場でブラウザ遷移を埋め込みにくい」ケースに合います。
ローカル端末にシークレットを焼き込まなくて済むので、ネイティブアプリやCLIでの実装負荷と安全性の折り合いをつけやすい構成です。

Visual Studio Codeまわりでも、拡張やAzure系の実装でデバイスコードフローを使う事例がありますし、GitHubもOAuth AppsのDevice Flowを案内しています。
ブラウザを開いて認可コードを戻すPKCE型の体験がきれいに作れるならそちらが本命ですが、CLI主体の導線ではDevice Flowのほうが自然に収まる場面があります。

一方で、ここを「非対話だからサービスアカウントのように扱ってよい」と誤解するとズレます。
Device Flowは、ユーザー関与を別チャネルへ逃がす方式です。
ユーザー同意、スコープ、失効というOAuthの骨格は残ります。
したがって、remote HTTPで人が使うMCPクライアントなら、ブラウザ遷移が成立する環境ではAuthorization Code + PKCE、CLI中心でブラウザ内蔵が難しいならDevice Flow、という切り分けが素直です。
Device Flow は、ユーザーの別デバイスやブラウザを介して認可を完了する方式であり、操作主体としての「ユーザーの同意」を維持する点が欠かせません。
これを「非対話だからサービスアカウント扱いでよい」と誤解しないようにしてください。

方式比較表

文章だけだと判断軸が混ざるので、導入速度と正式運用の観点で並べると次のようになります。

見方のコツは、導入の速さと、あとで必要になる運用統制を同じ土俵で比べることです。
APIキーは立ち上がりが速い反面、人数が増えた瞬間に「誰の権限か」という問いに弱くなります。
PKCEは初期実装の仕事は増えますが、同意、スコープ、失効、監査を同じ線で扱えるので、remote HTTPではこちらを基準にしたほうが設計がぶれません。
Device Flowはその中間ではなく、ブラウザ埋め込みが難しいクライアント向けの別解として見ると整理しやすくなります。

権限管理のベストプラクティス：最小権限・RBAC・ABAC

最小権限とスコープ設計

認可設計で最初に固めたいのは、「何を読めるか」と「何を書き換えられるか」を別物として扱うことです。
MCPではツール呼び出しがそのまま実業務の操作につながるので、単に「このサーバーを使える」という粗い許可では足りません。
read と write を分け、さらに admin を独立させて、不要な write をデフォルトで配らない設計にしておくと、事故の面積が一気に縮みます。
たとえばGitHub系のMCPなら、リポジトリ内容の参照、Issueの更新、設定変更は同列ではありません。
ドキュメント検索ツール、課題更新ツール、管理ツールを同じ権限束に入れると、閲覧だけで済む利用者まで変更権限を持つ形になります。

ここで効くのが、MCPツール単位のスコープ設計です。
サーバー全体に一つの広いスコープを付けるのではなく、repo.read、issue.write、settings.admin のように操作の意味ごとに切り分けます。
クライアント側にも、そのスコープが何を許すのかを明示しておくと、認可画面の判断材料と監査の両方が揃います。
CursorやClaude Codeのようにremote 。

監査ログにも、このスコープをそのまま残す設計が効きます。
誰が、どのクライアントから、どのMCPツールを、どのスコープで呼んだのかが一本で追えると、後から「なぜこの変更が通ったのか」を説明できます。
逆に、監査ログに「MCP call succeeded」としか残らない構成だと、認証はあっても認可の証跡が残りません。
運用ではツール名、操作種別、対象リソース、承認されたスコープを並べて残すだけでも、レビューの精度が変わります。

RBACの設計パターン

RBACは、まず現場を動かすには収まりのよい方式です。
部署や職種に合わせて「閲覧者」「編集者」「管理者」のようなロールを定義し、そのロールにスコープを束ねれば、利用者ごとの個別設定を減らせます。
たとえばVS CodeやCursorから同じGitOps用MCPサーバーに接続するチームでも、SREには repo.read と一部の write、監査担当には read のみ、運用管理者には admin を含める、といった割り当てに落とせます。
入退社や異動にも追従しやすく、まずはRBACから始める判断は堅実です。

ただし、RBACだけで長く回すと、例外をロールで吸収し続ける構造になりがちです。
開発部向けロール、運用部向けロール、夜間当番ロール、緊急対応ロールという具合に条件が増えると、役割の数が膨らみます。
いわゆるロール爆発で、設計書では整理されていても、現場では「似た名前のロールが多すぎて差がわからない」という状態に入りやすくなります。

私自身、GitOpsリポジトリを対象にしたMCP運用をRBACだけで始めたことがあります。
最初は「開発」「運用」「管理」の3段階で十分に見えたのですが、実際には部署ごとに触ってよいパスが違い、さらに時間帯によって変更可能な範囲も変わりました。
そこで例外をロールの追加で吸収し続けた結果、設計会議のたびにロール名が増えていきました。
閲覧はできるが昼間だけ書き込み可、別部署への昇格時だけ一時的に例外付与、といった条件が積み上がると、ロールの数が増えるわりに説明性は落ちます。
RBACは「誰にどの基本権限を持たせるか」を決める土台としては優秀ですが、条件付きの例外まで全部抱え込ませると、運用がねじれます。

RBACでは、基本権限の骨格に集中させるのが実務向きです。
組織上の役割に応じた標準権限をまず定義し、read/write/adminを役割単位で束ねる。
個別条件までロール名に埋め込まず、標準ケースを整理するための仕組みと割り切ると、ロールの意味が崩れません。

ABACの設計パターン

ABACは、利用者や対象データの属性で判定する方式です。
典型的には、部署、雇用区分、時間帯、対象リポジトリの分類、データ機密区分、接続元クライアントなどを条件に使います。
たとえば「開発部所属で、営業時間内で、機密区分が社内限定のリポジトリに対しては write を許可し、それ以外は read のみ」といった形です。
RBACが「誰という役割か」を主軸にするのに対し、ABACは「今この条件を満たしているか」を主軸にします。

私が先ほどのGitOps運用で最終的に落ち着いたのも、このABACの追加でした。
RBACで基本ロールを作ったうえで、部署属性と時間帯の条件を write 側にだけかけるようにしたところ、例外運用が目に見えて減りました。
ロールを増やす代わりに、「運用部で、定義された時間帯内なら本番系の変更申請を通せる」と条件で表現したほうが、実際の業務ルールに沿っていたからです。
これで権限棚卸しの会話も変わりました。
誰に何ロールを追加するかではなく、どの属性条件が業務ルールとして妥当かを議論できるようになります。

一方で、ABACは柔軟なぶん、判定理由が見えにくくなる欠点があります。
属性が増えるほど、ある操作が許可された理由を人間が追いづらくなります。
条件式が散らばると、設計者以外が読めないルール群になり、監査や障害対応で詰まります。
そこで実務では、属性の種類を最初から増やしすぎず、まずは業務に直結するものに絞るのが定石です。
部署、データ機密区分、時間帯のように説明可能な属性から始めると、ルールの意味を保てます。

ABACをMCPで使うときは、ツール単位スコープとの相性も見逃せません。
同じ write でも、Issue更新と本番設定変更では重みが違います。
そこで「どのツールか」をスコープで分け、そのうえで「誰が・いつ・どの属性条件で使えるか」をABACで絞ると、スコープの意味と条件判定が噛み合います。
write を一括で許すより、ツール別に分けたうえで属性条件を載せるほうが、誤許可の面積を抑えられます。

RBAC/ABAC比較表とハイブリッド指針

実務では、RBACとABACを二者択一で考えるより、骨格はRBAC、例外と文脈はABACと置いたほうが設計が安定します。
組織上の役割で大枠を決め、時間帯やデータ機密度、所属属性などの条件はABACで足す形です。
これならロールの数を抑えつつ、現場の業務ルールも反映できます。

使い分けの目安も、組織規模だけでは足りません。
変更頻度が低く、役割が固定的で、機密データも限定されるならRBAC中心で十分です。
逆に、部署横断のプロジェクトが多く、データ機密度ごとに扱いが変わり、時間帯や運用状態まで条件に入るならABACの要素が要ります。
MCPではツール呼び出しが直接操作に結び付くため、read は広く、write は属性条件で絞り、admin はごく少人数に閉じる、というハイブリッドが最も破綻しにくい構成です。

このときの勘所は、RBACとABACの責務を混ぜないことです。
ロールは標準権限、属性は例外条件と文脈制御、と役割分担を決めると、レビューでも「この人に新しいロールが必要なのか」「既存ロールに属性条件を足せば足りるのか」を切り分けられます。
MCPの認可は仕様準拠だけでは完成せず、そこに業務ルールをどう載せるかで実運用の質が決まります。
GitHubリポジトリのように変更の重みが大きい対象ほど、この粒度差がそのまま安全性の差になります。

DCRとIdP連携でつまずきやすいポイント

DCRの意義と現実

MCPの認可仕様では、動的クライアント登録であるDCRは「あると望ましい」側に置かれています。
文言としてはSHOULDでも、remote HTTP のMCPをチーム単位で増やしていく局面では、実務上の圧力はもっと強いです。
新しいサーバーやツールが次々に増えるたび、管理画面で手作業登録してクライアントIDを配る運用では、登録待ちがボトルネックになり、結局は共通クライアントの使い回しに流れやすくなります。
そうなると、誰がどのクライアントとして振る舞っているのかが曖昧になり、前のセクションで触れた最小権限や監査の設計が現場で崩れます。

そのためDCRは、仕様の理想論というより、台数と接続先が増えたときに手作業を吸収するための実装要素として見るほうが実態に合います。
MCP Authorization Specification (2025-06-18)でも認可まわりはクライアントとサーバーの協調動作として整理されています。
実際に詰まるのは「登録を誰が、どの粒度で、どこまで自動化するか」です。
DCRを入れれば終わりではなく、DCRを入れた瞬間から登録面が新しい攻撃面にも運用面にもなります。

ここで見落とされがちなのが、DCRが便利なほど、野良クライアントも生まれやすいという点です。
私もKeycloakでDCRを評価したとき、まず承認フローなしで登録を通して挙動を見ました。
すると、テスト用のクライアントが想像以上に増え、命名も揃わず、どれが継続利用前提でどれが一時検証用なのか数日で見分けがつかなくなりました。
最終的には、登録審査を必須にし、命名規則も固定しないと運用に乗らないと腹落ちしました。
DCRの論点は自動化そのものではなく、自動化された登録をどう統制するかにあります。

主要IdPの対応差と注意点

現実の導入では、OktaGoogleKeycloakAuth0のどれを使うかで、DCRの進め方が揃いません。
差が出るのは「DCRがあるかないか」だけではなく、どこまで無認証で登録できるのか、登録時に許せる項目の範囲はどこまでか、作成後に管理画面側の承認や追加設定が要るのか、といった運用の細部です。
ここが揃わないため、MCPクライアント側でDCR前提の設計をしても、IdP連携で止まりやすいのが利点です。

とくに無認証DCRは、仕様上は想定できても、実際には制約付きで扱われることが多い領域です。
OktaやGoogle系の構成を検討すると、公開登録そのものよりも、事前に許可した条件下での登録、もしくは管理されたアプリ作成フローとの併用に寄る場面が出てきます。
Auth0やKeycloakも含め、DCR対応は一枚岩ではありません。
登録可能なクライアント種別、リダイレクトURIの扱い、初期スコープ設定、秘密情報の発行方針など、MCPクライアントの期待とIdPの流儀がずれる箇所が残ります。

この差は単純な機能比較だけで片付く話ではありません。
たとえば、各クライアント（Cursor／Claude Code 等）の公式ドキュメントを確認しても、DCR の自動登録範囲や resource パラメータの送出可否が明確でない場合があります。
実務では「クライアントが何を前提にしているか」と「IdP が何を許容するか」の交点で設計判断を行う必要があります。
クライアント固有の挙動を前提にする場合は、個別に該当ドキュメントやリリースノートを参照したうえで設計を固定してください。

『MCPの認可チュートリアル』でも、認証・認可はフローの成立だけでなく、メタデータ発見やチャレンジ、登録後のトークン処理まで含めて考える構成になっています。
DCRだけ切り出して「対応あり」で安心すると、登録後に求められるPKCE、audience 検証、リダイレクトURI整備、失効運用で止まります。
IdP選定では、DCRの有無より、MCPクライアントが必要とする登録パターンをそのIdPで再現できるかを見るほうが実務では役に立ちます。

DCRハードニングチェック

DCR を有効にした場合でも、クライアント側の自動登録挙動や resource パラメータの送出可否には製品ごとの差があります。
したがって、DCR を運用に組み込む際は、各クライアントと IdP の実装仕様を個別に確認したうえで、自動登録の範囲や審査ルールを決めることを推奨します。
DCRを有効にしたら、登録APIは実質的に入口になります。
ここを素通しにすると、認可基盤の外周だけ自動化されて、中身の統制が追いつきません。
最低限ほしいのは、登録クライアントの検証、レート制限、監査、緊急失効、承認付きワークフローの5点です。

レート制限も欠かせません。
DCRは成功時だけでなく失敗時の試行も含めて記録しないと、登録面への探索行為を見落とします。
MCPクライアント側では短寿命トークン運用が前提になりやすく、長時間の作業中には更新処理が連続します。
Bearer JWT のTTLを5分以下で切る構成では、8時間の作業セッション中に最大で約96回の更新処理が発生しえます。
トークン更新と登録要求は別物ですが、認可基盤に対するリクエスト総量が増える点は同じです。
登録APIだけ無防備だと、普段の認可トラフィックに紛れて異常を埋もれさせます。

監査では、いつ誰が登録し、誰が承認し、どの設定が入っていたかを追える必要があります。
ここで効くのが承認プロセスです。
運用上は少し面倒でも、無審査の登録より、登録申請と承認を分けたほうが後から説明できます。
加えて、インシデント時にクライアントを即座に止められる緊急失効の導線も要ります。
トークン失効だけでなく、該当クライアント自体を無効化し、関連する認可を追跡できないと、登録されたクライアントが残骸として居座ります。

エンタープライズで本当に苦しくなるのは、DCRの成否よりも、その後の可視化です。
どの従業員が、どのMCPツールに、どの認可でアクセスできるのか。
どのクライアントが誰の同意にもとづいて動いているのか。
どの部門がどの外部サーバーを接続しているのか。
この問いに即答できないと、OAuth 2.1 やDCRを採用していても、統制の説明ができません。

MCPはツール呼び出しが業務操作に直結するため、SaaS連携より可視化要求が細かくなります。
たとえば社内ドキュメント検索と、運用設定変更と、請求データ参照では、同じ「接続済みクライアント」でも重みが違います。
しかもクライアントはCursorClaude CodeVisual Studio Codeのように分散し、サーバー側も社内実装と外部提供が混ざります。
このとき必要なのは、認可サーバーの一覧画面ではなく、誰がどのMCPツールを使えて、その根拠となる同意・ロール・属性条件は何かをまとめて見られることです。

ところが2025年時点では、この可視化の成熟度にばらつきがあります。
IdPの監査機能は強くても、MCPツール単位まで自然に見通せるとは限りません。
逆にMCPクライアント側で接続ログが見えても、組織全体のポリシーと突き合わせる画面が弱いことがあります。
結果として、認可の真実はIdP、MCPサーバー、クライアントログ、チケット運用の四か所に分かれ、監査のたびに突合が必要になります。

このギャップは、RBACやABACの設計が良くても残ります。
ロール設計が整っていても、「そのロールが実際にどのMCPツール実行に結び付いたか」が見えなければ、運用者は安心できません。
エンタープライズでDCRを語るときは、登録の自動化より、集中管理、棚卸し、組織ポリシーとの整合まで含めて見る必要があります。
仕様の理想はDCRで接続を滑らかにし、認可で権限を絞ることですが、現場ではその前後にある可視化の不足が、導入速度より先にボトルネックになります。

監査・ログ・運用で外せない項目

監査ログの必須項目テンプレート

MCP を本番運用に載せると、認可そのものより「後から何を説明できるか」が効いてきます。
最低限そろえたいのは、同意付与、スコープ変更、トークン発行/失効、異常リクエスト、クライアント登録/削除、管理者操作の6系統です。
ここが欠けると、障害対応でも監査でも、IdP の画面とクライアントログとサーバーログを往復しながら推測で埋める時間が増えます。

実際、同意イベントとスコープ変更を Syslog に流して運用したことがありますが、異常時の事後調査で「誰が」「どのツールに」「どの権限を」与えたのかがその場で引けるだけで、復旧の速度が目に見えて変わりました。
MCP はCursorClaude CodeVisual Studio Codeのようにクライアントが分散しやすく、接続先も社内外にまたがるので、監査証跡を認可サーバーの管理画面だけに閉じ込めないほうが実務では強いです。

ログ項目は、イベント名だけでは足りません。
少なくとも、発生時刻、主体ユーザーまたはサービス主体、対象クライアントID、対象MCPサーバー、対象ツールまたはリソース、変更前後のスコープ、結果、失敗理由、相関ID、操作元IP、管理者操作なら承認者と実行者を分けて持たせたいところです。
特にスコープ変更は、単に scope_updated ではなく、どの権限が追加され、どの権限が削除されたのかまで残さないと、後から差分が読めません。

MCP Authorization Specification (2025-06-18)のような仕様を見ても、認可はフロー成立で終わりではなく、保護リソースへのアクセス文脈まで含めて扱う前提です。
運用側ではそれを監査証跡に落とし込む必要があります。
たとえば異常登録では、クライアント登録要求の急増、登録直後の権限過大な同意、想定外の redirect URI、失敗を繰り返すトークン要求をひとつの相関IDで束ねておくと、単発の失敗ログでは見えない探索行為が浮きます。

シークレット管理/ローテーション

シークレット管理は、認可フローを通したあとに運用を崩す典型的な穴です。
MCP サーバー、認可サーバー連携、外部 API 連携で複数の秘密情報が混在するため、ストア分離、ローテーション、最小使用権限の3点を同時に回す必要があります。
アプリ設定ファイル、CI/CD、実行環境、ローカル開発端末で同じシークレットを共有する構成だと、棚卸しの時点で所在が追えなくなります。

実務では、用途ごとに保管場所を分けるだけで事故の形が変わります。
たとえば MCP サーバーが使う外部 API の資格情報と、OAuth クライアントシークレットと、管理用のブレークグラス資格情報を同じストアに置くより、役割ごとに分離してアクセス権も切ったほうが、漏えい時の影響範囲を限定できます。
最小使用権限は人の権限だけでなく、シークレット自身にも当てはまります。
読み取り専用の統計 API と変更系 API で同じ資格情報を使わないだけでも、侵害後の横展開を止めやすくなります。

ローテーションは「定期的に変える」だけでは不十分で、切り替え中に止まらない設計まで含めて考える必要があります。
新旧シークレットを短期間併存させる、失効順序を決める、トークンキャッシュの掃除タイミングをそろえる、といった運用手順がないと、夜間に一斉失効して原因不明の 401 が続出します。
前述の可視化の問題ともつながりますが、誰がどのシークレットを参照しているかが分からない状態では、ローテーションは変更作業ではなく賭けになります。

長寿命シークレットも見逃せません。
API キー中心の暫定運用がそのまま残ると、棚卸しの対象から外れた共有秘密が静かに増えます。
そこで警告と棚卸しを定期化し、最終使用日、所有チーム、用途、失効予定を資産として持つ形に寄せると、残骸化を防げます。
MCP 文脈ではクライアント登録情報も資産の一部なので、クライアント削除や失効イベントとシークレット台帳を突き合わせられる状態が望ましいです。

短命トークン運用と再認証UX

短命トークンを前提にした設計では、セキュリティだけでなく再認証 UX が運用品質を左右します。
Bearer JWT の TTL を 5 分前後に置く構成は珍しくありませんが、この条件だと長時間の作業セッション中に更新処理が何度も走ります。
トークン自動更新が静かに回る限りは問題になりませんが、リフレッシュ失敗時の導線が弱いと、利用者には「急にツールが黙った」ように見えます。

この差が出るのは、UI と CLI の設計です。
CursorやVisual Studio Codeのようにブラウザ遷移を伴うクライアントでは、再同意や再認証が必要になったとき、どの権限が切れ、どの画面に戻れば復旧するのかを明示したほうが混乱が少なくなります。
CLI 中心の導線では、デバイスコードやブラウザ認可に飛ばす文言が曖昧だと、利用者は再実行を繰り返してしまい、異常リクエストのノイズが増えます。

ここで効くのが、再認証フローそのものを疎通試験に含めることです。
正常系の「初回ログインできた」だけで終えると、本番で失効・同意撤回・スコープ変更が起きた瞬間に詰まります。
UI なら同意取り消し後の復帰導線、CLI なら端末をまたいだ再同意の文言と時間切れ後のメッセージまで確認しておくと、障害票の大半が説明不足だったと気づきます。
Understanding Authorization in 。

同意付与やスコープ変更のログがここでも効きます。
短命トークン運用では「なぜ失敗したのか」を利用者の体験だけで判断できません。
トークン失効なのか、スコープ縮小なのか、管理者によるクライアント無効化なのかを切り分けるには、認可イベントの監査証跡が必要です。
再認証 UX は見た目の親切さではなく、失敗理由を運用と利用者の両方が読める状態にする設計だと捉えたほうが、MCP では現実的です。

監視・SIEM連携とコスト管理

監査テレメトリは集めるほど安心に見えますが、MCP の運用ではコスト面の設計を先に入れておかないと、観測基盤のほうが先に痛みます。
特にMicrosoft Sentinelのような SIEM 連携は、統合インターフェース自体に追加料金がなくても、クエリ実行や取り込みは従量課金の考え方で積み上がります。
MCP の認可イベントは、同意、スコープ変更、トークン発行/失効、異常リクエスト、管理者操作と種類が多く、しかも短命トークン運用では件数が増えやすいため、全部を同じ粒度で永続保存すると費用対効果が崩れます。

コスト感覚は、周辺サービスの従量課金を見るとつかみやすいのが利点です。
たとえばAWS Cost Explorer APIは 1 リクエストあたり 0.01 ドル、トレース基盤のLangSmithは extended traces が 1,000 traces あたり 5.00 ドルです。
監査ログも同じで、1件あたりは小さく見えても、イベント種別が増え、相関分析や再検索が増えると積み上がります。
MCP の監査証跡は「全部保存するか、捨てるか」の二択ではなく、何をフル保存し、何を集約し、何をサンプリングするかを分けたほうが現実的です。

向いている設計は、インシデント調査に直結するイベントを厚く残し、ノイズの多い正常系を段階的に間引くやり方です。
たとえば同意付与、スコープ変更、クライアント登録/削除、管理者操作、異常登録、トークン失効は完全保存に寄せる価値があります。
成功したトークン発行や定常的な introspection 相当のイベントは、集約メトリクスと詳細ログを分ける構成のほうが、SIEM 側の検索コストを抑えながら異常検知も維持できます。

ここで見落としやすいのが、監視対象を増やすと運用者の可読性も落ちる点です。
Syslog、アプリログ、IdP 監査、SIEM アラートを全部別名義で持つと、コスト以前に追跡が散ります。
監査証跡の設計段階でイベントIDや相関IDを共通化しておくと、収集先が分かれても一連の事象として追えます。
MCP では「接続できない」事象の裏に、トークン失効、同意撤回、クライアント削除、シークレット期限切れが並ぶので、監視とコスト管理は別テーマではなく、同じ観測設計の話として扱うほうが運用の筋が通ります。

よくある失敗例と安全な設計チェックリスト

アンチパターン集

MCP の認可設計で事故につながる失敗は、難しい暗号処理の欠落より、運用を急いだ結果の「雑な単純化」から起きることが多いです。
とくに remote HTTP の構成で、stdio の気軽さをそのまま持ち込むと、権限境界が一気に曖昧になります。

典型例が、単一高権限トークンに全部を載せる設計です。
CursorでもClaude Codeでも複数の MCP サーバーやツールを横断して使う場面がありますが、読み取り系ツールと管理系ツールを同じアクセストークンで通すと、漏えい時の被害範囲が広すぎます。
社内ドキュメント参照と本番設定変更が同列にぶら下がる構成は、実装側には楽でも、監査や失効の局面で制御不能になります。
権限分離がないままトークンだけを秘匿しても、防波堤が一枚しかありません。

長寿命トークンも同じ発想の延長線上にあります。
短命トークンは更新処理が面倒に見えるため、PoC の段階で「まずは長く持たせる」と逃げたくなりますが、その判断がそのまま本番に残ることが少なくありません。
MCP まわりでは Bearer JWT を短く切る運用例が普通にあり、長時間の作業セッションでは更新回数も積み上がります。
そこで更新処理を正しく組まずに寿命だけ延ばすと、再認証 UX の問題をセキュリティ低下で隠しているだけになります。

audience 未検証は、見た目には動いてしまうぶん厄介です。
実際、検証環境で audience を見ないまま受ける設定にしたところ、別環境向けに発行したトークンが偶然通る状態を再現できました。
署名が正しく、iss と exp だけ見ていると、一見まともに見えるのですが、肝心の「そのトークンがこの保護対象のために出されたものか」が抜け落ちます。
この手の不具合は本番障害になるまで発見されにくく、しかも再現すると背筋が冷えます。
以後は audience 検証を単独項目でチェックリスト化し、レビュー時に必ず潰す運用に変えてから、同種の見落としは止まりました。

MCP 特有の落とし穴としては、MCP サーバーからのアクセストークン横流しも外せません。
いわゆるパススルーで、クライアントが取得したアクセストークンをそのまま MCP サーバーが下流 API に投げる設計です。
短期的には実装工数を削れますが、サーバーの責務が「ツール提供」から「ユーザー資格情報の中継」に変質します。
すると、ログ、エラーハンドリング、再送、キャッシュのどこかでトークンが残り、境界が壊れます。
『Understanding Authorization in MCP』 でも、保護対象と認可の境界を明確に扱う流れが整理されていますが、パススルーはその境界を曖昧にする代表例です。

もう一つ多いのが、独自実装しすぎる問題です。
401 challenge を省いて独自エラーコードだけ返す、PRM を出さずに設定画面の手入力で押し切る、RFC 8707 の resource を使わずベンダー独自パラメータに寄せる、といった設計は、最初のデモでは通ってもクライアント相互運用で詰まります。
Visual Studio CodeやCursorのように MCP クライアントの接続導線が整ってきた今、仕様から外れた近道は、接続できるクライアントを狭めるコストとして返ってきます。

安全設計チェックリスト

安全側に倒す設計は、項目を増やすことではなく、境界ごとに確認点を固定することです。
実運用で使っているチェックリストも、抽象論ではなく「この時点で何を判定したか」を残せる形にすると回ります。

まず入口で必要なのは、stdio と remote HTTP を分けて扱うことです。
ローカルプロセス接続の stdio で成立する運用と、HTTP 越しに保護対象へ触る remote では前提が違います。
stdio はローカル限定・短期用途・閉じたメンバー運用に寄せやすく、remote は OAuth 中心で権限境界を明示しないと破綻します。
ここを曖昧にしたまま共通テンプレートで組むと、過剰実装か過少防御のどちらかになります。

そのうえで、remote 側ではPRM の提供と401 challenge の実装が土台になります。
保護対象メタデータが出ていれば、クライアントはどの認可サーバーを見に行くか判断できますし、未認証時に challenge を返せば再認証導線が閉じません。
独自の接続説明ページに誘導するより、プロトコルとして復旧経路を返すほうが、クライアント側の実装負担も減ります。
MCP 認証関連で参照される仕様更新が 2024-11-05、2025-03-26、2025-06-18 と続いているのを見ても、接続性は独自仕様ではなく整合性で稼ぐ段階に入っています。

認可要求では、RFC 8707 の resource 対応を入れておくと、対象リソースの意図が明確になります。
少なくともサーバー側は resource を理解し、audience に反映できる状態がほしいところです。
クライアント側の明示サポートは公式情報で確認できない製品もありますが、サーバー実装が備えていれば、将来の相互運用で詰まりにくくなります。

トークン検証は、audience / iss / exp をまとめて見るのが基本です。
署名検証だけで通してはいけません。
audience を落とすと別リソース向けトークン混入を防げず、iss を落とすと発行元のなりすましに弱くなり、exp を落とすと失効管理の前提が崩れます。
ここはコードレビュー時に「検証しているつもり」の実装が混ざりやすいので、関数単位で明文化しておくほうが確実です。

権限面では、最小権限スコープを固定化し、読み取り・更新・管理を分けます。
スコープ名の粒度は組織ごとに違っても、少なくとも「全部入り一個」は避けるべきです。
MCP サーバーが複数ツールを束ねる場合ほど、この分離が監査ログの価値を上げます。
どのツール呼び出しが、どの権限セットで走ったかを後から読めるからです。

運用系の確認点としては、DCR の扱いを決めることも抜けやすいのが利点です。
自動登録に寄せるのか、管理画面承認に寄せるのか、登録後に誰が命名・棚卸しするのかが曖昧だと、クライアントが増えた瞬間に管理不能になります。
GitHubの OAuth では PKCE や Device Flow の整備が進んでいても、DCR を公式に提供している確認は取れていません。
つまり、IdP や AS ごとに「登録の自動化前提」は置けないわけで、MCP 側は DCR 前提の夢を見るより登録運用を先に決めたほうが崩れません。
『GitHub Changelog』 で PKCE サポートが明示された流れを見ても、実装の成熟度は機能ごとに段差があります。

実務で使える形に落とすと、チェック項目は次のようになります。

• 接続方式を stdio と remote HTTP に分類し、同じ認可前提で扱っていない
• remote HTTP 向けに PRM を提供している
• 未認証時に 401 challenge を返し、再認証導線が閉じていない
• RFC 8707 の resource を受け取り、対象リソースを識別できる
• audience / iss / exp をサーバー側で検証している
• 単一高権限トークンではなく、最小権限スコープへ分割している
• DCR または手動登録の運用責任者と棚卸し手順が決まっている
• 同意、トークン発行、失効、スコープ変更、管理者操作まで監査ログが網羅されている
• 緊急失効の動線があり、クライアント削除やトークン失効を即時反映できる
• レート制限があり、再認証失敗や異常試行で AS と MCP サーバーが一緒に詰まらない

PKCE support for OAuth and GitHub App authentication - GitHub Changelog

PKCE (Proof Key for Code Exchange) is now supported and recommended for user authentication in OAuth and GitHub Apps. Th

github.blog

エンタープライズ追加チェック

エンタープライズで詰まりやすいのは、認証そのものより「権限が時間とともにズレること」です。
最初の設計が正しくても、異動、兼務、委託、組織変更でロールや属性が現実とずれます。
RBAC や ABAC を前段で設計していても、ロールと属性の定期レビューがないと、古い例外が残り続けます。
結果として、今の業務に不要なスコープが消えず、監査では説明できない穴になります。

DCR の承認フローも、企業利用では設計そのものより統制が問われます。
誰でもクライアントを増やせる状態だと、MCP サーバーの入口が増えるたびに監査対象も膨らみます。
承認者、用途、接続先、要求スコープ、失効責任者を紐づけて残しておくと、インシデント時に「このクライアントは何者か」で止まりません。
承認抜きの自動登録は、PoC には向いても統制ラインとは衝突します。

地味に効くのが、クライアント命名規則です。
人が読めない client 名は、SIEM や IdP 監査画面で追跡不能になります。
部門、用途、環境、本番可否を名前で判別できるだけで、緊急停止の判断が速くなります。
これがない環境では、削除対象の取り違えが起きやすく、障害対応中に余計な停止を招きます。

観測面では、可視化ダッシュボードがあるかどうかで運用品質が変わります。
ほしいのは派手な画面ではなく、クライアント数、失効件数、スコープ別利用、401 challenge 発生、再認証失敗、環境別の認可イベントをひと目で追えることです。
前のセクションで触れた監査・SIEM の話ともつながりますが、ログを保存しているだけでは、権限の肥大化や異常導線は見えてきません。

AS 側の。
アプリ側が短命前提で作っていても、認可サーバーの設定変更で寿命が伸びると、設計上の前提が静かに崩れます。
逆に短すぎる設定に変更されると、リフレッシュ負荷と失敗率が跳ね上がります。
MCP の長時間セッションでは、短命トークンを支える自動更新の安定性がそのまま利用体験になります。
短く切る方針だけを掲げて、AS 設定とクライアント実装の整合を見ていない構成は、現場で必ずほころびます。

エンタープライズでは、技術仕様の準拠だけで安全になったとは言えません。
ロール棚卸し、DCR 承認、命名規則、可視化、AS 設定確認までつながってはじめて、MCP の認可設計が運用に耐える形になります。
特に audience 未検証のような「動くから見逃す」不具合は、こうした横断チェックに組み込んだ瞬間から発見率が上がります。
仕様の理解だけで止めず、レビュー項目として固定することが、現場では一番効きます。

シナリオ別設計例：stdio / remote HTTP / enterprise

ローカルstdioの設計雛形

ローカルの stdio は、同じ MCP でも remote HTTP と設計の重心が違います。
ここで現実的なのは、まず API キー、次に Device Flow です。
CursorやClaude Codeのようにローカルプロセスとして MCP サーバーを起動する場面では、利用者がその端末の所有者であり、接続範囲も限定されるため、ブラウザ同意フローを毎回前提にするより、環境変数とローカルのシークレット保管を土台にしたほうが運用がまとまります。
ブラウザを開けない CLI 中心の体験では、OAuth を使うにしても Device Flow のほうが筋が通ります。

設計の雛形としては、API キーを OS のシークレットストアまたは環境変数から読み込み、MCP サーバー側ではそのキーに対して最小スコープを割り当てます。
読み取り専用のツールと更新系ツールを分け、個人用キーを使い回さず、利用者を限定した短い配布範囲で閉じる形です。
ローカル用途では共有トークンが一見手軽でも、誰が何を実行したかの線がすぐ消えます。
監査も中央集権の詳細イベントより、端末上の操作ログ、起動ログ、ツール実行ログを残すほうが実態に合います。

Device Flow を選ぶ場面は、ローカルだが API キーを埋め込みたくないケースです。
たとえばVS Code系の拡張やターミナル主体のクライアントでは、ブラウザで認可して端末側へ戻す流れより、別画面でコードを入力して認証を完了する方式のほうが収まりがいいことがあります。
ブラウザ同意フローは remote HTTP の正式運用で主役になりますが、stdio では「使えれば採る」ではなく「ブラウザが自然に開ける利用形態か」で位置づけを分けたほうが迷いません。

このシナリオの DoD は、設定、ログ、失効、同意 UI を次の粒度まで落とせていることです。

stdio では、認可の豪華さより「漏れたときにすぐ止められるか」と「誰の端末で動いていたか」が効いてきます。
小規模なローカル利用を OAuth 2.1 前提に寄せすぎると、設計だけ立派で日常運用が空洞になります。

チーム向けremote HTTP雛形

チームで共有する remote HTTP の MCP サーバーでは、中心になるのは Authorization Code + PKCE です。
ここではブラウザ同意フローが主役で、利用者ごとに認証し、同意とスコープを結び付け、短命アクセストークンで回す構成に切り替わります。
CursorやClaude Codeのようなクライアントが remote MCP に接続するときは、ローカル stdio の延長として API キーを持ち込みたくなりますが、複数人で継続利用する段階では、ユーザー単位の同意と失効が取れない構成がすぐに運用上の詰まりになります。

この雛形で外せないのが、PRM の提供、resource パラメータの受け取り、audience 検証です。
resource がないままトークンを取ると、認可サーバーは意図しない audience のトークンを返し、MCP サーバー側で aud 不一致になります。
実際にCursorからAtlassian系の remote MCP 接続を試したとき、対象リソースを明示しない構成では認証画面までは進んでも、その後のトークン利用で弾かれる挙動を確認しました。
UI 上は「接続できそうに見える」のに、サーバー側では audience が合わず失敗するので、ここは実装より先に設計で固定しておくほうが手戻りが減ります。
RFC 8707 の resource は地味ですが、実運用では接続成功率を左右する部品です。

PKCE については、RFC 7636が定義する code_verifier と code_challenge を使う前提で組み、ネイティブクライアントやデスクトップクライアントでは S256 を通す設計に寄せるのが自然です。
『RFC 7636』 が示した通り、これは認可コード横取り対策のための拡張で、remote HTTP の公開面を持つなら外しにくい要素です。
さらに、PRM で認可サーバーの場所を発見させ、401 challenge から再認証へ戻せる導線を持たせると、クライアント実装差に引きずられにくくなります。

短命アクセストークンもこのシナリオでは前提です。
Bearer JWT の TTL が 5 分以下で切られる設計は珍しくなく、長時間の作業ではトークン更新が断続的に発生します。
8 時間の作業なら最大で約 96 回の更新が起こりうる計算なので、更新処理を人手前提で考えると破綻します。
ブラウザ同意フローは初回認可と再認証のために置き、通常の継続利用は自動リフレッシュで回す。
この役割分担にすると、3 時間程度の連続作業でも利用者の手を止めにくくなります。

スコープ設計は「サービス単位」では粗すぎます。
ツール × 操作で切るほうが MCP の利用実態に合います。
たとえば issue の参照と issue の更新、ナレッジ検索と管理操作を別スコープに分ける考え方です。
DCR はここでいきなり全面自動化しなくても構いません。
段階導入にして、まずは手動登録で命名規則と棚卸しを固め、その後に自動登録の対象を限定して広げる形のほうが事故が少ないです。

このシナリオの DoD は次の通りです。

RFC 7636: Proof Key for Code Exchange by OAuth Public Clients

OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception a

datatracker.ietf.org

エンタープライズ雛形

規制業種や大規模組織では、remote HTTP の OAuth 2.1 構成を土台にしつつ、上に IdP 連携 と 統制運用 を積みます。
ここではMicrosoft Entra IDのような IdP と SSO、MFA を結び、MCP サーバー単体で認証を抱え込まない設計が軸になります。
利用者の本人確認は IdP 側、MCP 側は受け取ったトークンと属性で認可する役割に寄せるほうが、異動や退職、委託終了への追随が速くなります。

認可は RBAC だけでは足りず、ABAC だけでも運用負荷が高くなります。
実務では RBAC + ABAC のハイブリッド が収まりやすく、標準権限はロールで配り、機密区分、所属部門、データ所在地、時間帯のような条件を属性で補正する構成になります。
MCP でいえば read/write/admin の芯はロールで持ち、例外条件は属性で絞る形です。
これなら職務変更があっても土台は保ちやすく、機密データだけ追加条件を掛ける運用にできます。

DCR もこの層では承認フロー込みで扱います。
新しい MCP クライアントを登録するときに、用途、接続先、要求スコープ、失効責任者、命名規則まで紐づけて残す。
PoC では省略されがちな手順ですが、本番系ではここが監査の入口になります。
GitHubの OAuth でも PKCE や Device Flow の整備は進んでいますが、DCR を公式に前提化できるわけではないので、企業側の承認フローで埋める発想が現実的です。
『GitHub Changelog』 で PKCE サポートが明示された流れを見ても、認証の成熟と登録統制は別レイヤーとして扱う必要があります。

監査はローカルログではなく、集中管理が前提です。
IdP の認証イベント、MCP サーバーのツール実行、管理者操作、スコープ変更、失効処理を一つの監査線に載せ、SIEM へ流せる構成にします。
課金や API コストもこの段階では無視できません。
たとえばAWS Cost Explorer APIは 1 リクエストあたり 0.01 ドルなので、権限だけでなくツール呼び出し量も制御対象になります。
Microsoft Sentinel MCPも unified MCP server interface 自体に追加料金はなくても、クエリ実行は従量課金です。
エンタープライズの認可は「見せてよいか」だけでなく、「どこまで打たせるか」「何回まで許すか」まで含めて設計する必要があります。
レート制限とコスト上限は、セキュリティ設定というより経営管理と地続きです。

短命トークンと強制再認証もこのシナリオでは意味が変わります。
単に有効期限を短くするのではなく、高リスク操作や機密ツールの実行時に再認証を要求し、MFA と結び付けることで、平常作業と高リスク操作を分離します。
継続利用の快適さはリフレッシュトークンで維持しつつ、昇格操作だけは再確認を入れる形です。
これなら全員に重い認証を常時求めず、危険な場面だけ防御を厚くできます。

このシナリオの DoD は次の状態です。

同じ MCP でも、stdio は利用者限定のローカル制御、remote HTTP は OAuth 2.1 とブラウザ同意、エンタープライズは IdP・監査・統制の上乗せという順に設計が変わります。
認証方式を一つに決めて全シナリオへ当てはめるより、接続形態ごとに責任の置き場を変えたほうが、運用の穴が見えやすくなります。

コストインパクトと短命トークン設計の運用注意

従量課金の見積もり方法

MCP の認証を OAuth 2.1 側へ寄せると安全性は上がりますが、そのぶん「何回呼ばれるか」がそのままコストに跳ね返ります。
remote HTTP の MCP では、単発の API 利用よりも、エージェントが会話の途中で補助的にツールを何度も叩く挙動が起きやすく、従来の手動操作前提の見積もりだと外れます。
たとえばAWS Cost Explorer APIは 1 リクエストあたり 0.01 ドルです。
1 回の問い合わせで済むと思っていた処理が、MCP クライアントの再試行や追加フェッチ込みで複数回発火すると、件数はすぐに膨らみます。

ここで見るべきなのは、単価よりも「1 セッションあたり何回 API を呼ぶ設計か」です。
認証失敗時のリトライ、ツール選択の試行錯誤、エージェントの自己修正まで含めると、利用者の操作回数より API 呼び出し回数のほうが多くなる場面は珍しくありません。
とくにコスト確認系や監査検索系のツールは、1 回の自然言語の依頼に対して裏側で複数クエリを投げる構成になりがちです。
MCP サーバー単位で月額固定と考えるより、ツールごとの呼び出し密度を把握したほうが実態に近づきます。

実務では、見積もりを「認証」「業務 API」「監査基盤」の 3 層に分けると崩れにくくなります。
認証そのものは直接の API 課金が見えにくくても、再認証回数やトークン更新失敗による再試行が後段の API 呼び出し数を押し上げます。
業務 API はAWS Cost Explorer APIのように単価が明示されているものを基準に、1 ユースケースで何回叩かれるかを数えます。
監査基盤は後述するようにログ量やクエリ回数が効いてくるため、成功系だけでなく失敗系も含めて見積もる必要があります。

SIEM やログ基盤も同じ発想です。
Microsoft Sentinel MCPは unified MCP server interface 自体に追加料金はありませんが、クエリ実行は従量課金です。
つまり「MCP でつながったので無料で観測できる」のではなく、「問い合わせのたびに分析基盤へクエリが飛ぶ」と捉えたほうが現実的です。
監査用途のクエリをリアルタイムで細かく打つ構成は安心感がありますが、日常的なオペレーションまで高頻度クエリに寄せると、監視コストが本番処理に追いついてきます。
そこで私は、保持期間を長く取るログと、即時性だけを見たいログを分け、前者は圧縮と集約、後者は短い保持で回す設計を採ることが多いです。
認証イベントや権限変更は保持を厚くし、通常の成功リクエストは必要な粒度に落として残すほうが、監査線を保ちながら費用の伸びを抑えられます。

監査・トレース強化の費用対効果

MCP の本番運用では、ログを増やせば安心になるとは限りません。
どの層のトレースにお金を払うのかを決めないまま拡張すると、調査の役には立つが請求だけが増える状態になります。
たとえば運用ツールではHypr MCP Proが公式サイトで月額 10 ドル、LangSmithの extended traces が 1k traces あたり 5.00 ドル、base から extended への upgrade でも 1k traces あたり 2.50 ドルです。
固定費のHypr MCP Proと、利用量に比例するLangSmithでは、予算の考え方を分けたほうが判断しやすくなります。

固定費のツールは、利用頻度が増えるほど 1 回あたりの負担が薄まります。
traces 課金は、開発・検証・CI/CD のどこで多く発生しているかを追わないと、想定より先に請求が立ち上がります。
私は一度、extended traces を一時的に最大化したまま夜間の CI/CD を流してしまい、翌朝に課金の伸び方を見て設定を見直したことがあります。
人が触る開発時間帯の障害解析には細かいトレースが効くのですが、夜間の自動実行まで同じ粒度で取り続けると、価値よりコストの伸びが先に来ます。
その経験以降は、本番、開発、CI でトレースの粒度を分け、さらに時間帯ごとにサンプリング率を切り替える前提で設計するようになりました。

監査の費用対効果は、「事故の再現に何が必要か」から逆算すると判断しやすくなります。
認証失敗の原因切り分けに必要なのは、全文トレースよりも challenge、要求スコープ、対象リソース、再試行回数、失効タイミングの相関であることが多いです。
逆に、エージェントの意思決定やツール選択の揺れを分析したい局面では extended traces の価値が出ます。
全イベントを最高粒度で残すより、監査ログとデバッグトレースの役割を分けたほうが、費用に対して得られる情報の密度が上がります。

SIEM 側も同様で、全件を長期保存して毎回フルクエリを打つより、インシデント性の高いイベントを優先して検索可能にしておくほうが運用と予算の折り合いが付きます。
たとえばトークン失効、権限昇格、管理者変更、同一主体の連続失敗は厚めに残す一方で、平常時の成功ログは要約指標へ寄せる構成です。
MCP の監査は「見える量」ではなく「説明できる粒度」で考えたほうが、道具の価格と組織の責任が噛み合います。

短命トークンと再認証UX/リトライ戦略

短命トークンは漏えい時の被害を狭める一方で、再認証導線が弱いと利用者体験を壊します。
Bearer JWT の TTL 例として 5 分以下の運用は珍しくなく、長時間の作業セッションでは更新処理が連続します。
8 時間の作業なら、5 分 TTL では最大で約 96 回の更新機会が発生しえます。
ここで毎回 UI を出していたら作業にならないので、平常時は静かに更新し、失敗時だけ意味のある再認証へ切り替える構成が要ります。

実装で差が出るのは、有効期限切れを待ってから 401 を受けるか、期限切れの手前で先回りするかです。
私は後者を基本にしています。
トークンの残り寿命を見て事前に更新し、更新に失敗したときだけ UI に認証導線を戻すほうが、利用者は「急に壊れた」と感じません。
CursorやClaude Codeのようにブラウザ認可と相性のよいクライアントでは、初回同意後の継続利用は裏側で回し、高リスク操作や refresh 失敗時だけ明示的に再認証へ送る構成のほうが収まりがよいです。

リトライ戦略も、単純な即時再送ではコストと混乱を増やします。
期限切れ、ネットワーク断、権限不足、認可サーバー側エラーを同じ扱いにすると、失敗 1 回で API 呼び出しが雪だるま式に増えます。
期限切れなら一度だけ更新を試し、その結果で再送する。
認可エラーなら再認証へ遷移する。
サーバー負荷や一時障害ならバックオフを入れて再試行する。
これを分けるだけで、無駄な API 課金と UI の往復を抑えられます。

再認証 UX では、利用者が「なぜ求められているのか」を理解できることも欠かせません。
平常の read 操作では静かな更新に寄せ、write や管理操作に入る瞬間だけ追加認証を出すと、負担の位置が明確になります。
エンタープライズで MFA を組み合わせるなら、この分岐はさらに効きます。
全操作を同じ重さで扱うのではなく、リスクの高い呼び出しだけ認証強度を引き上げることで、短命トークンの安全性と日常作業の連続性を両立できます。

コスト面でもこの設計は効きます。
期限切れを待って 401 を多発させる構成は、失敗ログ、再試行、監査クエリまで連鎖して、認証の話がそのまま観測コストの増加につながります。
反対に、事前更新、明確な再認証導線、原因別リトライ、バックオフを組み合わせると、失敗回数そのものが減り、API とログの両方で無駄打ちが減ります。
短命トークンはセキュリティのための設定ですが、運用では UX と請求額まで一体で設計したほうが、導入後の摩擦が少なくなります。

まとめと次のアクション

要点サマリー

判断の軸は明快です。
CursorClaude CodeVS CodeのようなMCPクライアントでも、stdio は APIキーや Device Flow の実務適性が高く、remote HTTP は OAuth 2.1 を中心に据えると設計がぶれません。
MCPサーバーは保護対象そのもの、つまり Resource Server として扱い、PRM の整備、resource と audience の検証、短命トークン、監査の4点を先に固めると、後工程の例外対応が減ります。

仕様の基準点は 2025-03-26 版と 2025-06-18 版に置きつつ、IdP や DCR の対応は製品ごとに揃っていません。
CursorのMCPドキュメントのような実装側の現実を見比べながら、段階導入で詰める進め方が現実的です。

着手順は、まず自分たちの MCP サーバーを stdio 向け、remote 向け、両対応のどれかに分類するところから始めます。
そのうえで、PRM を返せるか、resource と audience を検証しているか、ツールごとに read／write／admin を切り分けた権限表があるかを棚卸しします。
### 移行計画の立て方

高権限のAPIキーを一度に止めるより、remote から OAuth 2.1 へ寄せ、残る stdio を限定用途へ閉じ込める順番のほうが崩れません。
移行計画では、最初に監査ログの最小セットを決め、その次に read 系ツールから短命トークンへ移し、write と admin を別フェーズに分けると、利用者体験と統制の衝突を抑えられます。

実務では、この順番が効きました。
先に監査ログの最小セットを固めておいたことで、その後に権限を広げても、新しいSaaSを足しても、何を記録し何をレビューするかで迷わずに済みました。