Amazon Bedrock AgentCore による AI エージェントのエンドユーザー OAuth 同意管理

AIエージェントは、ユーザーに代わってGitHubやSlackなどのサービスにアクセスする必要があることがよくあります。エージェントがアクションを実行する前に、ユーザーはプロバイダーで認証を行い、リクエストされたアクセスを明示的に承認する必要があります。次に、アプリケーションは、結果として得られるOAuthグラントを、それを承認したユーザーと安全に関連付ける必要があります。このプロセスはセッションバインディングと呼ばれます。

以前は、AgentCore Identity（Amazon Bedrock AgentCoreの機能）のthree-legged OAuth (3LO)フロー（OAuth 2.0認可コードフローとしても知られています）を使用するお客様は、独自のセッションバインディングインフラストラクチャを構築してホストする必要がありました。これには、認可URLの提示、パブリックなHTTPSコールバックのホスト、戻ってきたユーザーの認証、ブラウザセッションの管理、およびフローを完了するためのCompleteResourceTokenAuthの呼び出しが含まれていました。

AgentCore Identityは、Amazon Bedrock AgentCoreの機能であるAgentCore Gateway向けのマネージドなWebエクスペリエンスおよびセッションバインディングエンドポイントであるConsent portalを提供するようになりました。ゲートウェイ用のポータルを作成し、そのURLをユーザーと共有します。ユーザーは組織のアイデンティティプロバイダー（IdP）で認証し、エージェントが利用可能なサービスを確認し、個々のプロバイダーに同意を与えます。ポータルはブラウザのリダイレクトとセッションバインディングを処理し、AgentCore Identityは結果として得られるトークンをそのトークンボルトに保存します。

この機能は、Kiro、Claude Code、Cursor、Visual Studio CodeなどのIDEやModel Context Protocol (MCP)クライアントを通じてアクセスされるエージェントに特に有用です。ユーザーはツールを呼び出す前に同意を与えることができ、その後のツール呼び出しでは、そのユーザーのために既に保存されているトークンを使用できます。この投稿では、ソフトウェア開発アシスタントを例として使用します。AWSマネジメントコンソールとブラウザでの管理者およびエンドユーザーのエクスペリエンスを順に説明し、結果として生じるアクティビティをAWS CloudTrailで確認する方法を示します。

図1：Consent portalは企業のIdPでユーザーを認証し、そのIAM実行ロールを使用して設定されたゲートウェイターゲットを検出し、プロバイダー接続を提示し、セッションバインディングを完了して、ユーザーごとのトークンをAgentCore Identityのトークンボルトに保存します