セキュアな認可付きリモートMCPサーバーを AWSマネージドサービスでつくろう！ Manato Takai, Ph.D. JAWS Festa 2025 in 金沢 

自己紹介 高井　真人 株式会社カミナシでID管理・認証認可基盤 の開発をしています。 好きなRFCは8628。 博士（工学） 

今日話すこと、話さないこと 想定する聴講者 - セキュアなリモートMCPサーバーを自作したい開発者 - 組織内外にリモートMCPサーバーを安全に提供していきたい推進者 セッションのゴール - MCPの認可仕様の概要を把握できている - MCPの認可仕様に沿ったMCPサーバーの実装課題を理解できている - 上記実装課題に対してどのような解決策があるかパターンの一つを学べる 

MCPと MCPの認可仕様 

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クライアント 

MCPの認可仕様 2025-03-26版の仕様からHTTPトランスポートなMCP限定でOAuth 2.1ベースの認可仕様が策定 この発表では現時点での最新仕様である2025-06-18版を前提として話をすすめる MCPサーバー （OAuthリソースサーバー） 認可サーバー MCPサーバーの認可仕様 2025-06-18版から認可サーバーは リソースサーバーであると明確化された RFC Draft OAuth 2.1 RFC9728 保護リソースサーバーメタデータ RFC8414 認可サーバーメタデータ RFC7591 動的クライアント登録 4つのOAuth標準仕様に従って構成される 

MCPの認可仕様：基本的なフロー MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> 

MCPの認可仕様：基本的なフロー MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> MCPサーバーに接続するために、どの認可サーバーから 認可を取得すればいいのかといった情報を取得する 保護リソースメタデータを要求 

MCPの認可仕様：基本的なフロー MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> 認可サーバーとのやり取りに必要な ● 動的クライアント登録エンドポイント ● 認可エンドポイント ● トークンエンドポイント の情報を取得 保護リソースメタデータを要求 認可サーバーメタデータを要求 

MCPの認可仕様：基本的なフロー MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> 保護リソースメタデータを要求 認可サーバーメタデータを要求 動的クライアント登録 MCPクライアントが認可リクエストするために、自身を OAuthクライアントとして登録する。 MCPの仕様では動的クライアント登録に対応していなくても クライアントIDとシークレットをハードコードしてもよいと あるが、例えばMCP Inspectorでは動的クライアント登録の フローを前提として動く。 [1] MCP Inspector: https://github.com/modelcontextprotocol/inspector 

MCPの認可仕様：基本的なフロー MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> 認可コードフローを 実行してユーザーの認可を得る 保護リソースメタデータを要求 認可サーバーメタデータを要求 動的クライアント登録 認可コードフロー 

MCPの認可仕様に関する 実装上の課題 

MCPの認可における実装上の課題 MCPサーバー （OAuthリソースサーバー） 認可サーバー RFC Draft OAuth 2.1 RFC9728 保護リソースサーバー メタデータ RFC8414 認可サーバーメタデータ RFC7591 動的クライアント登録 Cognitoも含めて、この2つの仕様に対応して いるIDaaSやOSSの認可サーバーはほぼない 多くの一般的な認可サーバーは認可サーバーメタデータや動的クライアント登録に未対応だが、 MCPの認可仕様に沿った認可付きのリモートMCPサーバーを作るには、これらの仕様に対応した認可 サーバーを用意しなければならない RFC Draft OAuth 2.1 

MCPサーバーとクライアントの間に認可やルーティングなどを担うゲートウェイを入れる MCPサーバーで提供したいツール部分と責務が分離して集中管理できるため、特に組織内でスケールして 利活用したい場合に有効に働く MCPゲートウェイパターン MCPゲートウェイ MCPサーバー #1 MCPサーバー #2 MCPサーバー #3 認可サーバー ルーティング、レートリミット、認可などの 責務をゲートウェイに集約 

MCPゲートウェイの実装パターン MCPサーバーのプロキシとしての ゲートウェイ 例：Bedrock AgentCore Gateway 認可サーバーも含めたMCP仕様との ギャップを埋めるゲートウェイ 例：hyprMCP Gateway、本発表構成 MCPゲートウェイ MCPサーバー 認可サーバー 認可サーバーメタデータや動的クライアント登録 ができないのでMCP Inspectorなどが通らない MCPゲートウェイ MCPサーバー 認可サーバー 仕様のギャップをMCPゲートウェイで吸収 MCPゲートウェイの実装パターンとして、MCPサーバー（リソースサーバー部分）だけカバーする形式と 認可サーバーの仕様ギャップもカバーする形式の2種類がある。 [2] Hypr MCP Gateway: https://github.com/hyprmcp/mcp-gateway 

Amazon API Gatewayと Amazon Cognitoで 実装してみよう 

Amazon API GatewayとAmazon Cognitoで認可付きリモートMCPサーバーを作ってみよう MCP Inspector MCPサーバー （AWS Lambda） 認可サーバー （Cognito） MCPゲートウェイ （API Gateway） 本発表で構成するMCPゲートウェイの全体構成図。 Lambdaの部分はElastic Container Service（ECS）など他のサービスでも問題ない。 なぜAPI Gatewayなのか： - 追加のコンピューティングリソースを用意しなくてよい - ルーティングやレートリミット、認可に関する基本的な機構はすでに揃っている *APIタイプはREST APIを選択 

API Gatewayで対応すべきこと 1 アクセストークンの検証とWWW-Authenticateによるブートストラップ 2 保護リソースサーバーメタデータエンドポイントの実装 3 認可サーバーメタデータエンドポイントの実装 4 動的クライアント登録エンドポイントの実装 

MCPゲートウェイで対応すべきこと 1 アクセストークンの検証とWWW-Authenticateによるブートストラップ 2 保護リソースサーバーメタデータエンドポイントの実装 3 認可サーバーメタデータエンドポイントの実装 4 動的クライアント登録エンドポイントの実装 

アクセストークンの検証とWWW-Authenticateによるブートストラップ MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> 保護リソースメタデータを要求 認可サーバーメタデータを要求 動的クライアント登録 認可コードフロー 

アクセストークンの検証とWWW-Authenticateによるブートストラップ Cognitoオーソライザー ゲートウェイレスポンス 

MCPゲートウェイで対応すべきこと 1 アクセストークンの検証とWWW-Authenticateによるブートストラップ 2 保護リソースサーバーメタデータエンドポイントの実装 3 認可サーバーメタデータエンドポイントの実装 4 動的クライアント登録エンドポイントの実装 

アクセストークンの検証とWWW-Authenticateによるブートストラップ MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> 保護リソースメタデータを要求 認可サーバーメタデータを要求 動的クライアント登録 認可コードフロー 

アクセストークンの検証とWWW-Authenticateによるブートストラップ Cognitoオーソライザー ゲートウェイレスポンス /.well-known/oauth-protected -resource/mcp Mock統合 Mock統合によって固定レスポンスを返すことができる。 最低限必要な保護リソースメタデータは認可サーバーと MCPサーバーのURLなので、インフラ構築時点で固定。 

MCPゲートウェイで対応すべきこと 1 アクセストークンの検証とWWW-Authenticateによるブートストラップ 2 保護リソースサーバーメタデータエンドポイントの実装 3 認可サーバーメタデータエンドポイントの実装 4 動的クライアント登録エンドポイントの実装 

アクセストークンの検証とWWW-Authenticateによるブートストラップ MCPクライアント MCPサーバー 認可サーバー 接続リクエスト WWW-Authentication: <保護リソースメタデータのURL> 保護リソースメタデータを要求 認可サーバーメタデータを要求 動的クライアント登録 認可コードフロー 

アクセストークンの検証とWWW-Authenticateによるブートストラップ Cognitoオーソライザー ゲートウェイレスポンス /.well-known/oauth-protected -resource/mcp Mock統合 /.well-known/oauth-authoriza tion-server Mock統合 保護リソースメタデータと同様にMock統合で固定レスポンスを 返す。 

MCPゲートウェイで対応すべきこと 1 アクセストークンの検証とWWW-Authenticateによるブートストラップ 2 保護リソースサーバーメタデータエンドポイントの実装 3 認可サーバーメタデータエンドポイントの実装 4 動的クライアント登録エンドポイントの実装 

動的クライアント登録エンドポイントの実装 Cognitoオーソライザー ゲートウェイレスポンス /.well-known/oauth-protected -resource/mcp Mock統合 /.well-known/oauth-authoriza tion-server Mock統合 /register AWSサービス統合 AWSサービス統合によってCognitoのAPI [1]をバックエンドとして利用する。 ただし、RFC 7591とリクエスト形式が異なるため、API Gatewayのリクエスト テンプレートマッピング機能によってMCPクライアントのリクエストを変換して Cognitoにクライントを作成する。 Cognitoの応答もRFC 7591と異なるためレスポンステンプレートマッピング機 能によって仕様ギャップを埋める。 [1] Cognito クライアント作成APIのリファレンス https://docs.aws.amazon.com/ja_jp/cognito-user-identity-pools/latest/APIReference/API_CreateUserPoolClient.html 

最終的なAPI Gatewayの設定 Cognitoオーソライザー ゲートウェイレスポンス /.well-known/oauth-protected -resource/mcp Mock統合 /.well-known/oauth-authoriza tion-server Mock統合 /register AWSサービス統合 認可、トークンエンドポイント /mcp 

これからもずっとゲートウェイを自作する必要がある？ 現在策定中のMCP仕様のドラフトでは、多くのOpenID Providerが対応している /.well-known/openid-configurationを認可サーバーの情報を取得するためのフォールバック先として 定義している。 これが標準となれば、Amazon Bedrock AgentCore + Cognitoの組み合わせでも問題なく動くはず。 

- 2025-06-18版の現行MCP認可仕様は4つのOAuth拡張仕様からできている - 一部の仕様は一般的なIDaaSにおいて非対応のため困ることが多い - MCPゲートウェイというアーキテクチャパターン - ルーティング、レート制限、認可やオブザーバビリティなどを集約できる - 複数のMCPサーバーをまとめて統制できるので組織的なスケールが容易 - Amazon API GatewayによるMCPゲートウェイの実装 - 追加のコンピューティングリソースが不要 - Mock統合やAWSサービス統合+リクエスト/レスポンスマッピングでCognitoと MCP認可仕様のギャップを埋める - 標準仕様を知ることの面白さ - 仕様を知ることで今なにができないか、これからどうなるかが分かってくる まとめ 

本日の内容に関連したブログとリポジトリもあるのでご興味があれば 

株式会社カミナシ https://kaminashi.jp