OAuth 2.0 認可 URL セッションバインディング
AgentCore Identity は、エージェントアプリケーションが ID プロバイダー/認可サーバーによって保護されたサードパーティーアプリケーションベンダーまたはリソースにアクセスするための OAuth 2.0 アクセストークンの取得を提供します。アプリケーションまたはリソースで、ユーザーが OAuth 認可コードフローを使用して明示的に認可する必要がある場合、AgentCore Identity はユーザーがアクセスに移動して同意するための認可 URL を生成します。次に、ユーザーが同意すると、AgentCoreアイデンティティはユーザーに代わってアプリケーションまたはリソースからアクセストークンを取得し、AgentCoreアイデンティティトークンボールトに保存します。
ただし、ユーザーが誤って認可 URL を別のユーザーに送信し、そのユーザーのアプリケーションまたはリソースにアクセスする可能性があるため、アプリケーションは認可リクエストを開始したユーザーが、アプリケーションまたはリソースへの同意を付与したユーザーと同じであることを確認する必要があります。そのためには、パブリックに利用可能な HTTPS アプリケーションエンドポイントを、ユーザー検証を処理する AgentCore Identity に登録する必要があります。
セッションバインディングの仕組み
次のフロー図と対応するステップは、OAuth 2.0 認可 URL セッションバインディングプロセスを示しています。
-
エージェントを呼び出す – エージェントコードは
GetResourceOauth2TokenAPI を呼び出して認可 URL を取得します。これは、元のエージェントユーザーが所有しているアプリケーションまたはリソースにアクセスしたい場合です。 -
認可 URL の生成 – AgentCore Identity は、ユーザーがアクセスに移動して同意するための認可 URL とセッション URI を生成します。
-
アクセストークンの認可と取得 – ユーザーは認可 URL に移動し、エージェントが自分のリソースにアクセスするための同意を付与します。その後、AgentCore Identity は、承認リクエストの送信元ユーザーを含む情報を使用して、ユーザーのブラウザを HTTPS アプリケーションエンドポイントにリダイレクトします。この時点で、HTTPS アプリケーションエンドポイントは、元のエージェントユーザーがアプリケーションの現在ログインしているユーザーと同じかどうかを決定します。一致すると、アプリケーションエンドポイントは を呼び出し
CompleteResourceTokenAuthて、AgentCore Identity がアクセストークンを取得して保存できるようにします。 -
エージェントを再呼び出ししてアクセストークンを取得する – アプリケーションが有効なレスポンスを返すと、エージェントアプリケーションは、最初にユーザーにリクエストされた OAuth2.0 アクセストークンを取得できるようになります。ユーザーが一致しない場合、アプリケーションは何もしないか、試行を記録します。
AgentCore Identity では、アプリケーションエンドポイントがユーザー ID を検証できるようにすることで、エージェントアプリケーションが常に承認リクエストを開始したユーザーと同じユーザーであり、アクセスに同意したユーザーであることを確認します。
実装の詳細
次の手順では、エージェントアプリケーションの OAuth 2.0 アクセストークンを取得するために、リソースプロバイダーからワークロード ID、OAuth 2.0 認証情報プロバイダー、および OAuth 2.0 アプリケーションクライアントを設定する手順を説明します。
サンプルコードは、作業アプリケーションの例として、OAuth 2.0 コールバックサーバーの実装
重要
ローカル環境で agentcore devで AgentCore CLI を使用する場合、ローカルの開発とテストを簡素化するために、CLI はコールバックエンドポイントをホストし、ユーザーセッションを検証するために CompleteResourceTokenAuth API を呼び出して OAuth 2.0 アクセストークンを取得するため、次のセットアップのステップ 1、2、4 をスキップできます。ただし、エージェントコードを AgentCore Runtime にデプロイする場合、エージェントランタイムに接続するウェブアプリケーションは、パブリックにアクセス可能な HTTPS コールバックエンドポイント自体をホストする必要があります。コールバックエンドポイントは、AgentCore Runtime が提供するエージェント ID UpdateWorkloadIdentityを使用して を呼び出し、現在のユーザーのブラウザセッションを検証した後に CompleteResourceTokenAuth API を呼び出して OAuth 2.0 認可フローを保護するAllowedResourceOAuth2ReturnUrlことで、ワークロード ID に対して として登録する必要があります。
OAuth 2.0 認可 URL セッションバインディングを実装するには
-
アプリケーション URL の作成 – ユーザー向けブラウザアプリケーションでは、ユーザーブラウザからアクセスでき、ブラウザリダイレクトからのリクエストを受け入れることができる新しい URL を作成してホストします。このページは、ユーザーがエージェントセッションを続行できるアプリケーションページにリダイレクトするか、現在アクティブなエージェントセッションを返すようにユーザーに指示する基本的なウェブページをレンダリングします。実装の後半では、このページは現在のユーザーのアクティブなセッションの検証に使用されるため、このページはアプリケーションユーザーセッションデータにアクセスして維持することもできます。
例えば、アプリケーションでは、ユーザーが などのプライマリアプリケーションページでエージェントとやり取りする場合があります
https://myagentapp.com/assistant。このような新しい URL を公開するとhttps://myagentapp.com/callback、プライマリアプリケーションページにリダイレクトされます。/callbackエンドポイントの実際のコードロジックは、このガイドに従って後で更新されます。 -
アプリケーション URL を使用してワークロード ID を更新する – (AgentCore CLI を介してローカルでテストする場合はスキップできます) AgentCore Identity がリダイレクトするアプリケーション URL を作成してホストしたら、アプリケーション URL が
AllowedResourceOauth2ReturnUrlとして登録されるようにワークロード ID を更新します。使用する IAM 認証情報に、新しいワークロード ID を作成するか、既存のワークロード ID を更新するかUpdateWorkloadIdentityに応じて、CreateWorkloadIdentityまたは を呼び出すアクセス許可があることを確認します。注記
AgentCoreランタイムまたはゲートウェイによってユーザーに代わって作成されたワークロード ID の場合、ワークロード ID 名は、サービスによって発行されたランタイム ID またはゲートウェイ ID に対応します。
UpdateWorkloadIdentityAPI コールの例:aws bedrock-agentcore-control update-workload-identity --name GoogleCalendarAgent \ --allowed-resource-oauth2-return-urls https://myagentapp.com/callback -
AgentCore Identity で OAuth 2.0 認証情報プロバイダーを作成する – OAuth 2.0 認証情報プロバイダーを完全に登録するには、
CreateOauth2CredentialProviderとUpdateOauth2CredentialProviderを呼び出すためのアクセス許可が必要です。以下の手順に従ってください。-
クライアント ID とクライアントシークレットのプレースホルダー
CreateOauth2CredentialProviderを使用して を呼び出します。 -
API レスポンスには、次のような OAuth コールバック (リダイレクト) URL が含まれます。
https://bedrock-agentcore.amazonaws.com/identities/callback/123-456-7890この値は、OAuth 2.0 リソースプロバイダーによって作成され、後で必要になる各プロバイダーに固有のものとして記録します。
-
リソースプロバイダー (Google や GitHub など) に移動し、OAuth 2.0 アプリケーションクライアントを作成します。リソースプロバイダーへの
CreateOauth2CredentialProvider呼び出しからサービスによって発行されたコールバック URL を、許可された OAuth 2.0 コールバック URL として指定します。 -
OAuth 2.0 アプリケーションクライアントを作成したら、OAuth 2.0 認証情報プロバイダーをこれらの値で更新する必要があるため、アプリケーションクライアントに割り当てられたクライアント ID とクライアントシークレットを記録します。
-
を呼び出し
UpdateOauth2CredentialProviderて、リソースプロバイダーから提供されたクライアント ID とクライアントシークレットを指定し、認証情報プロバイダーの作成時に提供されたプレースホルダー値を置き換えます。
-
-
CompleteResourceTokenAuth を呼び出すためのコードハンドラーを追加する – OAuth 2.0 認証情報プロバイダーを作成したら、アプリケーション URL ハンドラーで
CompleteResourceTokenAuthAPI を呼び出すためのコードと IAM アクセス許可を追加します。CompleteResourceTokenAuthAPI を呼び出す場合、アプリケーションは、OAuth 2.0user_id認可フローに関係するユーザーとエージェントアプリケーションを表すワークロードアクセストークンを生成するために使用された元のインバウンド ID プロバイダー OAuth トークンまたは文字列を提示する必要があります。この情報は、ユーザーのブラウザのアクティブなアプリケーションセッション (通常はブラウザ Cookie またはブラウザのローカルストレージ) から取得する必要があり、リモートセッションキャッシュからプルしないでください。さらに、AgentCore Identity によって生成される各認可 URL は、独自のセッション URI で一意に識別されます。このセッション URI は、セッションを目的のユーザーとバインドするために、ユーザー識別子と一緒に提示する必要があります。
重要
アプリケーションが
CompleteResourceTokenAuthAPI を呼び出す前に、アプリケーションは現在のユーザーにアプリケーションとのアクティブで有効なセッションがあることを確認する必要があります。これにより、アプリケーションは目的のユーザーを認可セッションに関連付けることができます。さらに、アプリケーションが依存するバックエンドサービスがある場合は、CompleteResourceTokenAuthAPI を呼び出すコードをバックエンドに移動し、アプリケーションにインバウンド ID プロバイダーの OAuth トークンまたはバックエンドuser_idに転送させることができます。サンプルアプリケーションコード:
def _handle_3lo_callback(self, request: Request) -> JSONResponse: session_id = request.query_params.get("session_id") if not session_id: console.print("Missing session_id in OAuth2 3LO callback") return JSONResponse(status_code=400, content={"message": "missing session_id query parameter"}) session_details = validate_session_cookies(request.cookies.get('my-application-cookie')) user_id = None if oauth2_config: user_id = session_details.get(USER_ID) if not user_id: console.print(f"Missing {USER_ID} in session_details") return JSONResponse(status_code=500, content={"message": "Internal Server Error"}) console.print(f"Handling 3LO callback for workload_user_id={user_id} | session_id={session_id}", soft_wrap=True) region = agent_config.aws.region if not region: console.print("AWS Region not configured") return JSONResponse(status_code=500, content={"message": "Internal Server Error"}) identity_client = IdentityClient(region) identity_client.complete_resource_token_auth( session_uri=session_id, user_identifier=UserIdIdentifier(user_id=user_id) ) return JSONResponse(status_code=200, content={"message": "OAuth2 3LO flow completed successfully"}) -
テスト – セットアップが完了したら、統合をテストする準備が整います。まず を呼び出し
GetResourceOauth2Token、ブラウザで返される認可 URL に移動します。OAuth 2.0 リソースプロバイダーで認可を完了すると、ブラウザがアプリケーション URL にリダイレクトされ、CompleteResourceTokenAuthAPI が呼び出されます。アプリケーションが有効なレスポンスを返すと、エージェントアプリケーションは、最初にユーザーにリクエストされた OAuth 2.0 アクセストークンを取得できるようになります。これらのトークンは、GetResourceOauth2TokenAPI を呼び出すことで取得できます。
その他の考慮事項
OAuth 2.0 認可 URL セッションバインディングを実装するときは、次の考慮事項に注意してください。
-
各認可 URL とそれに対応するセッション識別子は 10 分間のみ有効です。
-
アプリケーションコールバックエンドポイントを CSRF 攻撃から保護するには、 への API
GetResourceOAuth2Tokenコールに含める不透明な状態を生成することを強くお勧めします。アプリケーションはこの値を解析して、エージェントアプリケーションによって開始されたリクエストを処理していることを確認する必要があります。