2025-11-25最新版のMCP認可仕様を知り AWSサービスを使って実装しよう！ / Learn the Latest MCP Authorization Specs and Implement Them Using AWS Services

2025/12/20
JAWS-UG Presents - AI Builders Day
https://jawsug.connpass.com/event/371658/

2025-11-25最新版のMCP認可仕様を知り AWSサービスを使って実装しよう！

高井 真人
エンジニアリングマネージャー

Transcript

1. 2025-11-25最新版のMCP認可仕様を知り AWSサービスを使って実装しよう！ 株式会社 カミナシ ⾼井 真⼈ JAWS-UG AI Builders Day
2. ⾃⼰紹介 高井　真人 株式会社カミナシでID管理・認証認可基盤 の開発をしています。 好きなRFCは8628。 博士（工学）
3. Model Context ProtocolはAIアプリケーションが外部システムを利⽤するためのオープンソース標準仕様。 VSCodeやCursorといったクライアントとなるツール側の対応が進んだだけでなく、GitHubやFigma、 Notionなど各種サービスがMCPサーバーを公開してエコシステムが急速に発展している。 Model Context Protocol（MCP）とは IDE Chat Agent MCP MCPサーバー#1 MCPサーバー#2 MCPサーバー#3 MCPクライアント
4. Authentication or Authorization? Bedrock AgentCoreのドキュメントを読むと、Inbound/Outbound Authという⾔葉が状況によって 認証（Authentication）と認可（Authorization）の両⽅の意味をそれぞれ指して使われている。 https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-oauth.html https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-inbound-auth.html
5. AIエージェント OAuthによるMCPの整理 MCPサーバー#1 MCPサーバー#2 MCPサーバー#3 認可サーバー クライアント エディタ リソースオーナー リソースサーバー 認可（権限移譲）の同意 認可（権限移譲） 認可（権限移譲）された 範囲でのアクセス 今回話すMCPという⽂脈ではユーザーに権限移譲されたAIエージェント等がリソースサーバーへ 認可されたアクセスを⾏うという意味でInbound Authorizationを考える
6. MCPの認可仕様 基礎と最新版の差分
7. MCPの認可仕様の変遷 RFC Draft OAuth 2.1 RFC7591 動的クライアント登録 RFC9728 保護リソースサーバーメタデータ RFC8414 認可サーバーメタデータ RFC7591 動的クライアント登録 2025-03-26 2024-11-05 2025-06-18 2025-11-25 RFC Draft クライアントIDメタデータ 2025-11-25版から⾮推奨 ドラフト版 MCPの認可仕様はOAuthのドラフト仕様を積極的に取り⼊れながら、徐々に現実的にワークする仕様へと 進化しつつある 拡張仕様は他にもあるが、この発表では本筋の 認可仕様に絞って説明する
8. MCPの認可仕様：ネゴシエーションと認可フロー MCPクライアント MCPサーバー 認可サーバー 認可フローを⾏うための 準備のフロー 認可フロー 現状こちら側の仕様変更が活発
9. MCPの認可仕様：基本的なフロー MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: Bearer resource_metadata=”<保護リソースメタデータのURL>” scope=”<アクセスに必要なscope値>” 最新版改訂ポイント
10. MCPクライアント MCPサーバー 認可サーバー 接続リクエスト MCPサーバーに接続するために、どの認可サーバーから 認可を取得すればいいのかといった情報を取得する scopes_supportedパラメータで必要なスコープ値を明示すべき ことが記載された。 保護リソースメタデータを要求 MCPの認可仕様：基本的なフロー WWW-Authentication: Bearer resource_metadata=”<保護リソースメタデータのURL>” scope=”<アクセスに必要なscope値>” 最新版改訂ポイント
11. MCPクライアント MCPサーバー 認可サーバー 接続リクエスト 認可サーバーとのやり取りに必要な • 動的クライアント登録エンドポイント • 認可エンドポイント • トークンエンドポイント の情報を取得 保護リソースメタデータを要求 認可サーバーメタデータを要求 MCPの認可仕様：基本的なフロー WWW-Authentication: Bearer resource_metadata=”<保護リソースメタデータのURL>” scope=”<アクセスに必要なscope値>” 最新版改訂ポイント /.well-known/oauth-authorization-serverが見つからない 場合は/.well-known/openid-configurationを探すように修正
12. MCPクライアント MCPサーバー 認可サーバー 接続リクエスト 保護リソースメタデータを要求 認可サーバーメタデータを要求 WWW-Authentication: Bearer resource_metadata=”<保護リソースメタデータのURL>” scope=”<アクセスに必要なscope値>” （動的クライアント登録） OAuthクライアントとして認可サーバーに認識される方法として3つの方法をサ ポート。これまでと推奨が変わったので注意。 1. クライアントIDメタデータ（推奨） 2. 事前登録 3. 動的クライアント登録（フォールバック策/後方互換性のためで非推奨） なぜ動的クライアント登録が非推奨となったのか？ • MCPクライアント接続のたびに認可サーバーのクライアントデータが増加 • 誰でもクライアント登録できなければ接続できないが、誰でも登録できると いうことは攻撃をうける可能性が非常に高くなる [1] Client ID Metadata Documents Are the Future of MCP Client Registration: https://auth0.com/blog/cimd-vs-dcr-mcp-registration/ MCPの認可仕様：基本的なフロー 最新版改訂ポイント
13. MCPクライアント MCPサーバー 認可サーバー 接続リクエスト 保護リソースメタデータを要求 認可サーバーメタデータを要求 （動的クライアント登録） 認可コードフロー MCPの認可仕様：基本的なフロー WWW-Authentication: Bearer resource_metadata=”<保護リソースメタデータのURL>” scope=”<アクセスに必要なscope値>” 準備のフロー 認可フロー
14. 誰がどの仕様に準拠しないといけないか MCPクライアント MCPサーバー 認可サーバー RFC Draft OAuth 2.1 RFC9728 保護リソースサーバーメタデータ RFC8414 認可サーバーメタデータ RFC7591 動的クライアント登録 RFC Draft クライアントIDメタデータ RFC Draft OAuth 2.1 RFC Draft OAuth 2.1 RFC Draft クライアントIDメタデータ
15. AWSで実現するならどうなるか。その限界 AIエージェント MCPサーバー#1 MCPサーバー#2 MCPサーバー#3 クライアント エディタ リソースオーナー リソースサーバー 認可（権限移譲）の同意 認可（権限移譲） AgentCore Gateway 保護リソースメタデータ ※scopeの指定は未対応 認可コードフロー+PKCE OpenID Configuration クライアントIDメタデータ 動的クライアント登録 現状のAWSサービスの対応状況では事前登録クライアントでMCPの認可を動かすことは実現可能
16. まとめ • 2025-11-25版のMCP認可仕様にてより現実的に動く仕様へと進化 ◦ 動的クライアント登録が⾮推奨となりクライアントIDメタデータが推奨に ◦ 保護リソースメタデータでスコープ指定することで最⼩権限の原則に従った運⽤へ ◦ 認可サーバーメタデータエンドポイントのフォールバック先として広く実装されているOpenID Configurationエンドポイントが追加 • Amazon Bedrock AgentCore Gateway + Amazon Cognitoで基本的には動くように ◦ ボトルネックだった認可サーバーメタデータエンドポイントがOpenID Configurationエンドポイントを探す ようになったのでAmazon Cognitoで対応できるようになった ◦ スコープ指定やクライアントIDメタデータなど、まだ対応していない仕様の詳細もある
17. おまけ：AIの認証認可の難しさ ⻑時間⾃律的に動くAIエージェントからの 逐次的な権限移譲 エージェントやMCPが繋がった 権限移譲のチェイン エージェント⾃⾝の認証やガバナンス AIエージェントのユースケースをたくさん 知っている皆さんとぜひ議論させてください！
18. 株式会社カミナシ https://kaminashi.jp