概要
https://speakerdeck.com/hi120ki/mcp-authorization
詳細内容
## MCPの認証と認可
https://speakerdeck.com/hi120ki/mcp-authorization
本資料は、内製リモートMCPサーバー提供における認可仕様の課題、特にDynamic Client Registrationの難点と、その解決に向けたMCP仕様の今後の方向性を詳細に解説します。
**Content Type**: Technical Reference
**Scores**: Signal:5/5 | Depth:5/5 | Unique:4/5 | Practical:4/5 | Anti-Hype:5/5
**Main Journal**: 92/100 | **Annex Potential**: 90/100 | **Overall**: 92/100
**Topics**: [[MCP, 認証・認可, Dynamic Client Registration, OAuth, セキュリティガイドライン]]
「MCPの認証と認可」と題された本資料は、AI活用におけるModel Context Protocol (MCP) のセキュリティ課題に焦点を当てています。MCPサーバーはセキュリティベストプラクティスとしてリモート利用が推奨されており、実際にAtlassianやNotionなどが公式リモートサーバーを提供しています。これにより、設定ファイルからのアクセストークン排除、バージョン統一、利用状況の可視化といったメリットが生まれます。
しかし、独自の社内システムと連携するため内製のリモートMCPサーバーを開発しようとすると、認可仕様に大きな壁が立ちはだかります。公式の認可仕様はDynamic Client Registration (DCR) プロトコルを推奨していますが、Okta、Google Cloud、GitHub、Atlassianといった主要な認可サーバーの多くがDCRに未対応であるか、または管理者権限を必要とします。このため、「URLのみで接続できるMCP設定」という利便性を実現するのが現状では困難です。
内製で認可サーバーを開発するという選択肢もありますが、OAuth仕様への正確な準拠、多数のアクセストークンやOAuthクライアントの管理、非対応サービスごとの認可サーバー運用、そしてDCRのセキュリティ考慮事項への対応など、非常に大きな管理責任と技術的負担が伴います。
こうした課題に対し、MCPの仕様は現在進化を続けています。DCRを利用しない認可仕様の追加（SEP-991）や、IdP（Oktaなど）と連携してユーザー操作なしにアクセストークンを取得するエンタープライズ向け認可プロファイル（SEP-646）の試みが進められています。特にSEP-991は注目度が高いです。
Webアプリケーションエンジニアにとって、これはAIツール連携におけるセキュリティと運用の複雑性を理解する上で極めて重要です。MCPのようなプロトコルを用いた内製AIサービスを検討する際には、現状の認可プロトコルが抱える課題と、それがもたらす開発・運用上の責任を認識する必要があります。アクセストークンの有効期限の短期化や安全な保管ソフトウェアの利用など、直ちにできる対策を講じつつ、MCP仕様の今後の動向を注意深くキャッチアップすることが求められます。