AI News HubLIVE
サイト内リライト7 分で読了

AgentCore GatewayとMCPクライアントを使用したセキュアな認可コードフロー設定の構築

この記事では、Amazon Bedrock AgentCore GatewayでホストされるMCPサーバーのインバウンド認証メカニズムとしてOAuth認可コードフローを実装する方法を示します。このガイドを完了すると、各AIアシスタントリクエストが組織のアイデンティティプロバイダから発行された有効なユーザーアイデンティティトークンで認証される、本番環境対応のセットアップが完了します。

ソースAWS Machine Learning Blog著者: Swagat Kulkarni

現代の開発ワークフローでは、開発者はKiro統合開発環境（IDE）などのエージェンティックコーディングアシスタントにますます依存して、リモートツールやサービスとやり取りしています。しかし、組織はこれらのエージェンティックコーディングアシスタントとエンタープライズモデルコンテキストプロトコル（MCP）サーバーとの間の安全でアイデンティティ認証されたアクセスを提供するために、堅牢な認証メカニズムを必要とします。

Amazon Bedrock AgentCoreは、本番環境でAIエージェントをデプロイ、管理、スケーリングするのに役立つフルマネージドサービスです。その主要コンポーネントの1つであるAgentCore Gatewayは、エージェントとツールの通信をルーティングおよび保護するための集中エントリポイントを提供します。AIアシスタントがGatewayを介してMCPサーバーにリクエストを行う場合、そのリクエストは処理前に検証される必要があります。これはインバウンド認証と呼ばれます。許可されたユーザーとエージェントのみがMCPサーバーによって公開されたツールとサービスにアクセスできます。組織は通常、Okta、Microsoft Entra ID、Amazon Cognitoなどのアイデンティティプロバイダ（IdP）を介してユーザーIDを管理し、ユーザーを認証して、そのユーザーを確認するセキュリティトークンを発行します。

この記事では、Amazon Bedrock AgentCore GatewayでホストされるMCPサーバーのインバウンド認証メカニズムとしてOAuth認可コードフローを実装する方法を示します。このガイドの終了時には、各AIアシスタントリクエストが組織のアイデンティティプロバイダから発行された有効なユーザーアイデンティティトークンで認証される、本番環境対応のセットアップが完了します。

学習内容

  • 認可コードフローがAgentCore GatewayをMCPリソースサーバーとしてどのように機能するか。
  • 組織のアイデンティティプロバイダの段階的な設定。
  • AgentCore Gatewayのインバウンド認証設定。
  • Kiro IDEクライアントとの統合。

ソリューション概要

インバウンド認可コードフローOAuth設定では、AgentCore GatewayはMCPリソースサーバーとして機能し、AIクライアントがツールにアクセスする前に有効なアイデンティティトークンを要求します。

次の図は、AgentCore Gatewayを使用した認可コードフローのエンドツーエンドアーキテクチャを示しており、アイデンティティプロバイダ、AIクライアント、MCPサーバーの相互作用を含みます。

図1：認可コードフローアーキテクチャ図。

主要コンポーネント

このソリューションでは、以下のコンポーネントが連携して認証フローを完了します：

  • アイデンティティプロバイダ（IdP）：ユーザー認証を管理し、トークンを発行します。上の図ではAmazon Cognitoを参照していますが、組織のIdPでもかまいません。
  • ユーザー：IdPで認証するエンドユーザーであり、各リクエストでそのIDが検証されます。
  • Amazon Bedrock AgentCore Gateway：OAuthリソースサーバーとして機能し、トークンを検証してリクエストをMCPサーバーにプロキシします。
  • エージェンティックコーディングアシスタント：Kiro IDE。OAuthクライアントとして機能し、認証フローを管理します。
  • MCPサーバー：AIアシスタントがアクセスする必要があるバックエンドのツールとサービス。
  • MCP OAuthプロキシ（オプション）：エージェンティックコーディングアシスタント、IdP、MCPサーバー間の仕様標準化のギャップを埋めるのに役立ちます。MCP OAuthプロキシは、認可コードフローをサポートする標準化をもたらします。

インバウンド認可コードフロー

このフローにより、AIアシスタントがMCPサーバーに送信するすべてのリクエストが、ユーザーに属する有効なアイデンティティトークンで認証されるようになります。

  1. MCPクライアント接続 – エージェンティックコーディングアシスタント（Kiro IDEなど）がAgentCore GatewayのMCPエンドポイントへの接続を開始します。
  2. 認証チャレンジ – Gatewayはリクエストに有効なトークンがないことを検出し、HTTP 401を返します。このレスポンスには、GatewayのOAuth保護リソースメタデータエンドポイント（.well-known/oauth-protected-resource）を指すwww-authenticateヘッダーが含まれます。これはMCP仕様の保護リソースメタデータ（PRM）パターンに従います。
  3. ディスカバリ – MCPクライアントはGatewayから保護リソースメタデータを取得します。これにはIdPの認可サーバーディスカバリURL（例：https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration）が含まれます。
  4. ユーザーリダイレクト – MCPクライアントはユーザーのシステムブラウザを開き、PKCEチャレンジを伴ってIdPの認可エンドポイントにリダイレクトし、設定されたスコープ（例：openid profile email offline_access）を要求します。
  5. ユーザー認証と同意 – ユーザーはIdPログインページで資格情報を入力します。IdPはユーザーのIDを検証し、アプリケーションを認可するための同意を求めます。
  6. 認可コード付与 – 承認後、IdPはユーザーのブラウザをクライアントのローカルコールバックURL（クライアントのローカルリスナーによって管理される）にリダイレクトし、認可コードを付与します。
  7. トークン交換リクエスト – MCPクライアントは認可コードとPKCEコードベリファイアをIdPのトークンエンドポイントに送信します。
  8. トークン発行 – IdPは認可コードとPKCEベリファイアを検証し、アクセストークン（オプションでリフレッシュトークン）をMCPクライアントに返します。
  9. 認証済みMCPリクエストと検証 – MCPクライアントは以降のすべてのリクエストのAuthorizationヘッダーにアクセストークンを含めます。Gatewayはトークンの署名、有効期限、発行者、オーディエンスまたはカスタムクレームを検証し、リクエストをターゲットのMCPサーバーにプロキシして実行します。

図2：認可コードフローリクエストシーケンス。

設定概要

次の表は、認可コードフロー設定に必要な各コンポーネントの設定をまとめたものです。詳細な手順は「技術実装」セクションに記載されています。

コンポーネント | 必要な設定 --- | --- 1 | アイデンティティプロバイダ | 認可コードとリフレッシュトークンの付与を有効にしたOpenID Connect（OIDC）Webアプリケーションを作成します。 2 | AgentCore Gateway | インバウンド認証をJWTに設定します。ディスカバリURLをIdPの発行者に設定します（例：https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration）。 3 | Kiro IDE | 設定 > コネクタ（またはCLI経由）でGateway URLを追加します。Gatewayが適切なauthヘッダー付きで401 Unauthorizedを返すと、クライアントは自動的にOAuthフローをトリガーします。

技術実装

アーキテクチャとフローが確立したところで、各コンポーネントを設定します。このセクションでは、設定概要表で参照されている3つのコンポーネントの手順を説明します：

  • アイデンティティプロバイダ：OIDCアプリケーションを登録し、許可タイプ、リダイレクトURI、トークン設定を構成します。
  • AgentCore Gateway：JWTベースのインバウンド認証を有効にし、IdPのディスカバリエンドポイントを指定します。
  • MCPクライアント（Kiro IDE）：クライアントをGateway URLに接続し、エンドツーエンドのOAuthフローを検証します。

前提条件

以下の前提条件を満たしている必要があります：

  • AgentCore GatewayがデプロイされたAWSアカウント。
  • アプリケーションを設定する権限を持つアイデンティティプロバイダ（IdP）（例：Amazon Cognito、Okta、Auth0、またはその他のエンタープライズIdP）。
  • MCP OAuthプロキシ。
  • ローカルにインストールされたKiro IDE。
  • OAuth 2.0フローの基本的な理解。

ステップ1：組織のアイデンティティプロバイダを設定する

このステップでは、組織のアイデンティティプロバイダにOIDCアプリケーションを登録し、PKCEを使用した認可コードフローをサポートするように設定します。

1.1 OIDCアプリケーションを作成する

IdP管理コンソールにサインインし、新しいOIDC/OAuth 2.0アプリケーション統合を作成します：

  • サインイン方法：OIDC。
  • アプリケーションタイプ：Webアプリケーション。
  • 名前：AgentCore Gatewayクライアント（または任意の名前）。

1.2 許可タイプを設定する

次の許可タイプを有効にします：

  • 認可コード。
  • リフレッシュトークン。

1.3 リダイレクトURIを設定する

AIクライアントが使用するコールバックURLを追加します：

http://localhost:PORT/callback

PORTをクライアントが使用するポートに置き換えます。

1.4 トークン設定を構成する

IdPアプリケーション設定で、次の操作を行います：

  • トークンの有効期間：

- アクセストークンの有効期間：1時間（推奨）。 - リフレッシュトークンの有効期間：90日（セキュリティ要件に応じて調整）。 - IDトークンの有効期間：1時間。

1.5 設定を記録する

次の値を保存します。これらはGateway設定で必要になります：

  • クライアントID：アプリケーションの「一般」タブにあります（Kiro IDEクライアント設定に必要）。
  • 発行者URL：IdPの発行者URL（例：https://{yourIdPDomain}/oauth2/default）。
  • ディスカバリURL：IdPのOpenID Connectディスカバリエンドポイント（例：https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration）。

この設定では：

  • クライアントシークレットは不要 – このフローではPKCE（Proof Key for Code Exchange）を使用します。これはデスクトップアプリケーションなどのパブリッククライアント向けに設計されています。Kiro IDEはクライアントシークレットを必要とせず、使用しません。
  • クライアント設定にIdPエンドポイントは不要 – Kiro IDEはGatewayからOAuthエンドポイントを自動的に検出します。GatewayがディスカバリURLを返すため、クライアントに直接IdP URLを設定する必要はありません。

ステップ2：AgentCore Gatewayを設定する

アイデンティティプロバイダを設定したら、次のステップはAgentCore GatewayをIdPに接続して、受信トークンを検証できるようにすることです。

2.1 インバウンド認証モードを設定する

GatewayがJWTベースの認証を使用し、IdPのディスカバリエンドポイントを指すように設定します：

Gateway設定の例（デプロイ方法に応じて調整）

aws agentcore update-gateway \ --gateway-id \ --inbound-auth-type JWT \ --jwt-discovery-url "https://{yourIdPDomain}/oauth2/default/.well-known/openid-configuration" \ --region

2.2 カスタムクレーム検証

AgentCore Gatewayは標準のOAuth 2.0クレームに基づいてJWTトークンを検証し、異なるIdP実装に対応するためにカスタムクレーム検証をサポートしています。Gatewayはトークンに以下が含まれていることを期待します：

  • 標準クレーム：iss（発行者）、aud（オーディエンス）、exp（有効期限）、iat（発行時刻）、client_id（クライアントID）、scopes（許可されたスコープ）。
  • クライアント識別：GatewayはIdPに応じてさまざまなクレームを介してクライアントIDを検証できます。

他のIdPはクライアントID、スコープなどに異なるクレーム名を使用する場合があります（例：cid、azp、scp）。Gatewayでカスタムクレーム検証を設定して、IdPのトークン構造に一致させることができます：

  • カスタムクレーム：EQUALS（AgentCore Gateway：JWTの設定を参照）。
  • 例：cid EQUALS 0oaz7147z771FZmdQ697（Oktaなどcidを使用するIdPの場合）。

これにより、トークンが特定のアプリケーションに対して発行されたことが検証されます。

注：カスタムクレーム検証を使用する場合、Gatewayの「許可されたオーディエンス」フィールドは空のままにできます。カスタムクレームチェックが必要なクライアントID検証を提供します。

2.3 Gatewayのトークン検証を理解する

GatewayがIdPのディスカバリURLとクレームルールで設定されたので、ランタイムに受信トークンをどのように検証するかを見てみましょう。

AgentCore Gatewayは、ユーザーがOAuthトークンを取得した方法に依存しないように設計されています。Gatewayは以下を通じて取得されたトークンを区別しません：

  • クライアントクレデンシャルフロー（アプリケーションが直接認証する）。
  • 認可コードフロー（ユーザーが明示的に認証し同意を与える）。

Gatewayは、リクエストで提示されたOAuthトークンがGateway設定時に構成されたパラメータに基づいて有効であることのみを要求します：

  • トークン署名：IdPのディスカバリURLからの公開鍵に対して検証されます。
  • トークンの有効期限：トークンが期限切れでないことを検証します。
  • 発行者（issクレーム）：期待されるIdP発行者と一致します。
  • オーディエンスまたはカスタムクレーム：トークンがこの特定のGatewayまたはアプリケーションに対して発行されたことを検証します。
  • 標準OAuthクレーム：iat、expなどの必須クレームをチェックします。

ユーザーがクライアントクレデンシャルフロー、認可コードフロー、またはその他のOAuth許可タイプを通じてトークンを取得するかどうかに関係なく、Gatewayはすべてのトークンを同等に扱います。トークンがGateway設定で構成された検証チェックに合格する限り、リクエストは承認されます。この柔軟性により、ユースケースに合った認証フローを選択しながら、Gatewayレベルで一貫したセキュリティを維持できます。

2.4 Gateway設定を検証する

Gatewayエンドポイントにアクセスでき、認証が必要であることをテストします：

実際のトークンで認証をテスト

[AIコスト制御のためにトランケート]