Amazon Bedrock AgentCore Identityとは何か

Amazon Bedrock AgentCore Identityは、AIエージェントや自動化されたワークロード向けに設計された、アイデンティティおよびクレデンシャル管理サービスである。エージェントIDはワークロードアイデンティティとして実装され、業界標準のワークロードアイデンティティパターンとの互換性を保ちながら、エージェント固有の機能を持たせる特殊な属性を備えている。このサービスはAmazon Bedrock AgentCoreとネイティブに統合されており、エージェントやツールがユーザーに代わってAWSリソースやサードパーティサービスにアクセスする際の認証・認可・クレデンシャル管理を提供する（出典: AWS公式ドキュメント）。

Private Key JWTが解決する課題

AWS MLブログによれば、Amazon Bedrock AgentCore IdentityはエージェントのPrivate Key JWTクライアント認証をサポートするようになった。従来、エージェントがダウンストリームのIDプロバイダーのトークンエンドポイントに対して認証する際は、共有されるOAuth 2.0クライアントシークレットを使っていたが、Private Key JWTクライアント認証では、署名済みJSON Web Token（JWT）クライアントアサーションを使って認証する（出典: AWS Machine Learningブログ）。

公開鍵をIDプロバイダーに登録する一方で、対応する秘密鍵はAWS Key Management Service（AWS KMS）に保持され続ける。AgentCore Identityの公式ドキュメントは、この方式が「AgentCore Identityと認可サーバー間の共有シークレットを排除し、顧客が完全に制御する非対称鍵ペアに置き換える」ものだと説明している。認証はRFC 7523 Section 2.2に準拠したJWTクライアントアサーションによって行われ、クライアントシークレットの代わりに使われる（出典: Private Key JWT client authentication - Amazon Bedrock AgentCore）。

認証フローの仕組み

AWS MLブログは、顧客サポートエージェントが内部の注文APIから顧客の注文履歴を読み取る例を用いて、リクエストフローを次のように説明している。

  1. エージェントがAgentCore IdentityのGetResourceOauth2Tokenを呼び出し、注文API用のトークンをリクエストする。
  2. AgentCore Identityは、資格情報プロバイダーからクライアントID、KMSキーARN、署名アルゴリズムを読み取り、必要なペイロードクレーム（キー識別子や証明書のサムプリントなど、追加で設定したヘッダー/ペイロードクレームを含む）を持つ短命なJWTクライアントアサーションを構築する。そして、設定された署名アルゴリズム（RS256、PS256、ES256のいずれか）を使ってKMS非対称署名キーに対しkms:Signを呼び出す。
  3. AWS KMSがアサーションに署名し、署名結果をAgentCore Identityに返す。秘密鍵はKMSから外部に出ることはない。
  4. AgentCore Identityは、署名済みアサーションをgrant_type=client_credentialsおよびclient_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearerとともにIDプロバイダーのトークンエンドポイントにPOSTする。
  5. IDプロバイダーは登録された公開鍵に対して署名を検証し、アクセストークンをAgentCore Identityに返す。
  6. AgentCore Identityはアクセストークンをエージェントに返す。
  7. エージェントはそのアクセストークンで注文APIを呼び出す。
  8. 注文APIが顧客の注文履歴を返す。

この一連の流れの中で、秘密鍵が一度もKMSの外に出ない点が、共有シークレット方式との根本的な違いである（出典: AWS Machine Learningブログ）。

サポートされる認可フロー

Private Key JWT認証は3種類の付与フローで機能する。AWS公式ドキュメントは、これをクライアントクレデンシャル（M2M）、JWT認可グラントによるトークン交換（OBO）、認可コード（ユーザー委任アクセス）と整理している（出典: Private Key JWT client authentication - Amazon Bedrock AgentCore）。

  • Machine-to-machine（M2M）: エージェントが自分自身として振る舞う。人間のユーザーは介在せず、client_credentialsグラントを使う。トークンのサブジェクトはクライアント自体になる。
  • On-behalf-of（OBO）: エージェントが特定のユーザーの既存トークンを使って、そのユーザーの代理として振る舞う。ユーザーはどこかで既にサインイン済みであり、インバウンドのユーザートークンが存在する。AgentCore Identityは、クライアントアサーションによる自己認証を維持しつつ、インバウンドのユーザートークンをダウンストリームトークンに交換する。
  • 認可コード（ユーザー委任アクセス）: 上記2フローとあわせて、Private Key JWTクライアント認証はカスタムOAuth 2.0資格情報プロバイダー（CustomOauth2）上で3つのグラントフローすべてに対応している。

設定手順とKMS鍵の準備

資格情報プロバイダーを正しく設定するには、まずIDプロバイダー側のPrivate Key JWTクライアント認証の要件（署名アルゴリズム、公開鍵、必須のJWTクライアントアサーションクレーム）を確認する必要がある。署名アルゴリズムはprivateKeyJwtConfig内のsigningAlgorithmフィールドに対応しており、OAuth 2.0カスタム資格情報プロバイダーの作成・更新時に指定する（出典: Private Key JWT client authentication - Amazon Bedrock AgentCore）。

IDプロバイダーがアップロード済み公開鍵を受け付ける場合、SIGN_VERIFY用途の非対称KMS鍵ペアを作成する。鍵は資格情報プロバイダーと同じリージョンに存在する必要があり、そのKMSキーARNを資格情報プロバイダー作成時に指定する。作成後はkms:GetPublicKey APIを使って対応する公開鍵を生成する。このAPIはDERエンコードされたX.509公開鍵、またはSPKIを返す。IDプロバイダーによって要求される公開鍵フォーマットは異なり、公式ドキュメントは次のように具体例を挙げている。

  • Microsoft Entra: X.509証明書オブジェクトを要求する
  • Okta: JSON Web Keyを要求する
  • Ping Identity: 両方の形式に対応する

別のドキュメントでは、資格情報プロバイダー設定でクライアント認証方式としてPRIVATE_KEY_JWTを指定することで、AWS KMSキーに