【要約】MCP Authorization 仕様の課題と今後の展望
Model Context Protocol (MCP)[1] は、AI エコシステムにおける標準化を目指して進化を続けていますが、2025年3月26日に改訂された MCP Authorization 仕様には多くの課題が指摘されています。
以下のブログでは、MCP Authorization の仕様の課題と対策案について見解が記載されており、内容が興味深かったので要約します。
MCP Authorization 仕様の概要
2025年3月26日に改訂された MCP Authorization 仕様は、以下の要件を MCP サーバーに課しています。[2]
- MCP 認証実装は OAuth 2.1（PKCE必須）を実装する必要があること
- Dynamic Client Registration (動的クライアント登録)が推奨されていること
- Authorization Server Metadata (認可サーバーメタデータ) プロトコルの実装が推奨されていること
- サードパーティ認可サーバーを利用する場合、MCP サーバーはトークンマッピング機能が必須であること
これらはセキュリティ強化を目的としていますが、特にエンタープライズ環境では以下のような課題が生じています。
主な課題
1. リソースサーバーと認可サーバーの役割の混同
MCP Authorization 仕様では、MCP サーバーを「リソースサーバー」と「認可サーバー」の両方として扱う設計となっており、この設計では以下の問題を引き起こします。
- ステートレス vs ステートフル：トークン管理が必要になるため、MCP サーバーがステートフル化しスケール性が損なわれること
- 実装負担：MCP サーバー開発者に複雑なセキュリティコードやトークン管理機能の追加が求められること
- エンタープライズベストプラクティスとの乖離：既存の IdP（Identity Provider）インフラとの統合が困難であること
2. サードパーティトークン管理の複雑さ
外部 IdP を使用する場合でも、MCP サーバーは以下を担う必要があります。
- トークンマッピング：外部トークンと内部トークンを安全に関連付け
- トークン検証：外部トークンの有効性チェック
- トークンライフサイクル管理：期限切れや更新処理への対応
これらは実装・運用上大きな負担となり、特にエンタープライズ環境では現実的でない場合があります。
3. メタデータエンドポイントの分散化
仕様では各 MCP サーバーが独自に OAuth メタデータエンドポイント（例: /authorize, /token, /register）を公開することを求めていますが、クライアント側での実装が複雑化し、OAuth ベストプラクティスから逸脱します。
課題の対策案
これらの課題に対処するために、以下のようなアプローチが考えられます。
-
認可サーバーとリソースサーバーの分離
- MCP サーバーはリソースサーバーとしてのみ動作し、認証・認可は既存 IdP（Auth0, Keycloak, Okta など）に委任する
- IdP から発行されたトークンを検証し、そのクレーム情報に基づいてアクセス制御を行う
-
API ゲートウェイによるトークン検証
- API ゲートウェイでトークン検証を行い、安全性を確保した上で MCP サーバーへ転送する
- トークン検証後は SPIFFE や mTLS などのマシン間アイデンティティ技術で通信する
-
RBAC（ロールベースアクセス制御）の活用
- 検証済みトークンに基づく細粒度なアクセス制御を実現する
所感
現状の MCP Authorization 仕様はエンタープライズ導入という視点に立つと、まだまだ発展途上であり、今後のアップデートに期待したいです。
Discussion