2026年におけるMCP認証

Model Context Protocol (MCP) は、エージェントとサーバー間の通信方法を一変させました。当初は計算機のようなローカルツールから始まりましたが、現在はリモートサーバー上で動作しています。この変化により、認証が必須要件となりました。

MCPサーバーにOAuthを追加しようとするなら、常に変化し続ける対象（moving target）であることを覚悟してください。仕様は数ヶ月ごとに更新されます。また、エージェントによって適用されるルールのバージョンも異なります。

以下に、MCP認証の現状をまとめます。

コアとなる転換

あなたのMCPサーバーは、認可サーバー（authorization server）ではありません。リソースサーバー（resource server）です。

以前の仕様では、サーバー側でトークンやログインを処理することが強制されていました。これにより、サーバーは肥大化し、スケーリングが困難になっていました。Aaron Parecki氏やChristian Posta氏といった専門家はこの問題を指摘し、MCPサーバーはトークンの検証（validate）のみを行うべきだと主張しました。

現在、標準的なフローは以下の通りです：

• 認証されていないリクエストには401エラーが返される。 • エラーにより、クライアントはリソースのメタデータをどこで取得すべきかを知る。 • クライアントは適切な認可サーバー（OktaやKeycloakなど）を見つける。 • クライアントはトークンを取得し、それをMCPサーバーに提示する。 • サーバーはトークンを検証し、ツールを実行する。

断片化の問題

標準規格は存在するものの、エージェントごとに実装方法が異なります。

• Claude Desktop: 完全なOAuthフローを実行する。 • Claude API: 独自のベアラートークン（bearer token）の受け渡しを要求する。 • ChatGPT: 登録にCIMDを使用し、最新の仕様をサポートしている。 • Gemini: Google Cloud IAMとAPIキーを使用する。 • VS Code: GitHubおよびEntraプロバイダーをサポートしている。

つまり、あるエージェント向けに構築されたサーバーが、別のエージェントでは動作しない可能性があるということです。ベンダーによっては完全なログインフローを要求する場合もあれば、トークンを自前で管理することを求める場合もあります。

開発者のための3つの教訓

  1. リソースサーバーモデルをターゲットにする。アイデンティティプロバイダー（identity provider）になろうとしないでください。RFC 9728を使用してメタデータを提供し、audience（対象者）を検証してください。

  2. 二つの世界をサポートする。「独自のトークンを持ち込む（bring your own token）」形式のAPIコールと、完全なOAuthフローの両方に対応できるようにサーバーを構築してください。

  3. 絶え間ないアップデートを想定する。仕様はまだ進化の過程にあります。OAuth 2.1はまだドラフト段階であり、MCPプロトコルもまだ確立の途上にあります。

現在、MCPサーバーの構築は困難です。ルールは急速に変化しています。柔軟性を保ち、リソースサーバーモデルを堅持すれば、こうした変化を乗り越えられるでしょう。

出典: https://dev.to/0ndreu/mcp-authentication-in-2026-how-oauth-flipped-the-servers-role-and-why-every-agent-differs-11fm

オプションの学習コミュニティ: https://t.me/GyaanSetuAi