認可 ― 401が道案内をし、利用者が同意する

MCPサーバーは「守られる側」であって、発行する側ではない

OAuth の登場人物で言うと、MCPサーバーは Resource Server（保護リソース） です。トークンを受け取って検証する側であり、トークンを発行する側ではありません。

発行するのは認可サーバーです。これは別の場所にあります。自社の認証基盤でもよいし、既製品でも構いません。

この分担が効いています。MCPサーバーを作る人は、ログイン画面も、パスワードの保管も、多要素認証も作らなくてよい。既にある認可サーバーの前に、自分のサーバーを置くだけです。

MCPは特定の認証方式を決めていません。OAuth 2.1 の作法に沿うと言っているだけです。だから既存の仕組みに乗せられます。

401 が、道案内をする

未認証のクライアントが来たとき、サーバーは黙って断りません。どこへ行けばよいかを教えます。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp",
  resource_metadata="https://your-server.com/.well-known/oauth-protected-resource"

resource_metadata が道案内です。ここに「このサーバーについての説明書」の場所が書いてあります。

この形が素晴らしいのは、クライアントが事前に何も知らなくてよいことです。URLさえ知っていれば、1回叩いて401をもらい、そこから芋づる式に必要な情報へ辿り着けます。設定ファイルに認可サーバーのURLを書いてもらう必要がありません。

説明書を読むと、認可サーバーの場所が分かる

道案内の先にあるのが、保護リソースメタデータです。RFC 9728 で形が決まっています。

{
  "resource": "https://your-server.com/mcp",
  "authorization_servers": ["https://auth.your-server.com"],
  "scopes_supported": ["mcp:tools", "mcp:resources"]
}

クライアントはここから認可サーバーを知り、今度は認可サーバー側のメタデータ（OpenID Connect Discovery か OAuth 2.0 Authorization Server Metadata）を読んで、/authorize と /token の場所を知ります。

つまり3段階のたらい回しです。401 → 保護リソースの説明書 → 認可サーバーの説明書。面倒に見えますが、おかげでクライアントは1つのURLだけ知っていればよくなっています。

なお、scopes_supported に何でも並べるのはやめましょう。広すぎるトークンは、漏れたときの被害がそのまま広くなります。

利用者が同意して、はじめてトークンが出る

認可サーバーが分かったら、クライアントは自分を名乗る必要があります。方法は3つあります。

- 事前登録 — あらかじめ登録済みの client_id を持っている
- 動的クライアント登録（DCR） — その場で登録する。認可サーバーが対応していれば使える
- 手入力 — どちらも無理なら、利用者に登録情報を入れてもらう

そのうえで、ブラウザで /authorize を開き、利用者がログインして権限を許可します。ここは OAuth 2.1 の認可コードフロー + PKCE の作法どおりです。

戻ってきた認可コードをトークンに交換し、以降は Authorization: Bearer … を付けて MCP サーバーを呼びます。

順番を間違えないでください。トークンを出すのは認可サーバー、受け取って検証するのはMCPサーバーです。

自分宛でないトークンを、受け取ってはいけない

ここが一番の落とし穴です。仕様はこう書いています。

MCPサーバーは、自分に対して発行されたものではないトークンを受け取ってはならない（MUST NOT）。

なぜか。他のサービス向けに発行されたトークンをそのまま受け入れ、さらにそれを下流のAPIへ横流しすると、次が起きます。

- 検査の迂回。回数制限や検証が、トークンの宛先を前提にしているなら、それが効かなくなる
- 追跡できなくなる。下流のログには、実際に転送したMCPサーバーではない誰かが記録される
- 横展開。1つのサービスを落とせば、同じトークンで他のサービスにも入れてしまう

これを トークンの素通し（token passthrough） と呼びます。禁止事項です。

対策は、受け取ったトークンの audience（宛先） が自分であることを必ず検証することです。下流を呼ぶときは、自分が別に取得したトークンを使います。