MCPへ接続した瞬間に401 Unauthorizedが返ると、トークン・OAuth・ヘッダーのどこを疑うべきか迷いませんか？ 結論は、まず「Authorizationヘッダーが毎回付いているか」を確認し、次にトークンの有効期限・発行先・OAuthの検出情報を順番に切り分けることです。
401の原因はまず4つに分ける
なぜ401になるのでしょうか？ MCPの現行仕様では、401は「認証が必要」または「トークンが無効」のときに使われます。
- Authorizationヘッダーが付いていない、またはBearer形式ではない
- アクセストークンが期限切れ・無効になっている
- 別のMCPサーバー向けに発行されたトークンを送っている
- OAuthのProtected Resource Metadataや認可サーバー検出が正しく動いていない
この4点を上から確認すると、認証処理のどの層で止まっているかを絞り込みやすくなります。
Authorizationヘッダーを確認する
最初に見るのはヘッダーです。アクセストークンはURIのクエリ文字列ではなく、HTTPのAuthorizationヘッダーで送ります。
Authorization: Bearer <access-token>MCPの仕様では、このAuthorizationヘッダーをクライアントからサーバーへの各HTTPリクエストに含める必要があります。最初だけ付けて、その後のリクエストで抜けていないかも確認してください。
| 状態 | 確認ポイント |
|---|---|
| Authorizationなし | クライアント設定やプロキシでヘッダーが落ちていないか |
| Bearer以外 | Authorization: Bearer <token> になっているか |
| クエリにtokenを付与 | Authorizationヘッダーへ移す |
| 最初だけ成功 | 後続HTTPリクエストにもヘッダーが付くか |
トークンの有効期限と発行先を見る
ヘッダーが正しいのに401なら、次はトークン自体です。期限切れだけでなく、どのリソース向けに発行されたかも重要です。
MCPサーバーは、受け取ったアクセストークンが自分のリソース向けに発行されたものか検証します。別サービス向けのトークンを流用すると、形式が正しくても401になります。
- expなどの有効期限を確認する
- issuerが想定する認可サーバーか確認する
- audienceまたはresourceが対象MCPサーバーを指しているか確認する
- 上流API用のトークンをMCPサーバーへそのまま転送していないか確認する
用語解説：Audience / Resource
アクセストークンが「どのリソースで使うために発行されたか」を示す情報です。MCPサーバー側の想定と一致しないトークンは拒否されます。
WWW-AuthenticateからOAuthを追う
トークンを持っていない、または再認証が必要な場合は、401レスポンスのWWW-Authenticateを確認します。ここがOAuthフローの入口です。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"resource_metadataが返る場合、クライアントはProtected Resource Metadataを取得し、そこから利用すべき認可サーバーを特定します。
curl -i https://mcp.example.com/.well-known/oauth-protected-resource401は返るのにWWW-AuthenticateやProtected Resource Metadataが欠けている場合は、サーバー側のOAuth公開設定も確認対象です。
401と403を混同しない
認証できない401と、権限不足の403は切り分けます。答えが変わるためです。
| HTTP | 意味 | まず確認するもの |
|---|---|---|
| 401 | 認証が必要、またはトークンが無効 | Bearerヘッダー、期限、発行先、OAuth検出 |
| 403 | 認証済みだが権限が不足 | scopeやアクセス許可 |
401なのにscopeだけを変更し続けると原因から外れることがあります。まずトークンが有効に認証されているかを先に確認しましょう。
切り分けはこの順番で進める
- 401レスポンスのWWW-Authenticateを確認する
- Authorization: Bearer <token> が各HTTPリクエストに付いているか確認する
- トークンの期限切れ・無効化を確認する
- issuerと対象resource / audienceが正しいか確認する
- Protected Resource Metadataから認可サーバーを正しく検出できるか確認する
- 401ではなく403ならscope・権限側へ切り替える
ここまで確認すれば、「トークンを送れていない」のか「送ったトークンが拒否されている」のか「OAuth検出が壊れている」のかを分離できます。
（MCPサーバー全体の役割や接続の仕組みについては『MCPサーバーとは？仕組みと使い方』をご参照ください）
よくある質問
APIキーを付ければMCPの401は直りますか？
必ずではありません。MCPの標準的なHTTP認証はOAuth 2.1のBearerアクセストークンを前提とします。独自APIキー対応はサーバー実装ごとの仕様なので、そのMCPサーバーの認証方式を確認してください。
トークンがあるのに401になるのはなぜですか？
期限切れ、署名検証失敗、想定外のissuer、対象resource / audienceの不一致などが考えられます。トークンが存在することと、そのMCPサーバーで有効であることは別です。
401でscopeが表示された場合はどうしますか？
WWW-Authenticateにscopeが含まれる場合は、その情報をクライアント側の認可要求に反映します。ただし、まず有効な認証フローが成立していることを確認してください。
まとめ
MCPの401 Unauthorizedは、まずBearerヘッダー、次にトークンの有効性と発行先、最後にOAuthの検出情報を見ると整理しやすくなります。
まず手元の401レスポンスを開き、WWW-AuthenticateとAuthorizationヘッダーの2点から確認してみてください。そこが分かれば、次に直す場所が見えやすくなります。
