翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
プライベートキー JWT クライアント認証
プライベートキー JWT では、AgentCore Identity は、クライアントシークレットの代わりに RFC 7523 セクション 2.2 に従って、署名付き JWT クライアントアサーションを使用してダウンストリーム ID プロバイダーのトークンエンドポイントを認証します。プライベートキーが AWS Key Management Service (KMS) から出ることはありません。AgentCore Identity は、 を介して各アサーションに署名しますkms:Sign。ID プロバイダーは、クライアントアサーションの認証に使用される対応するパブリックキーを所有し、アクセストークンを返します。
この方法では、AgentCore Identity と認可サーバー間の共有シークレットが排除され、完全に制御できる非対称キーペアに置き換えられます。
プライベートキー JWT クライアント認証の仕組み
-
カスタム OAuth 2.0 認証情報プロバイダーは
clientId、、非対称 KMS 署名キーの ARN、およびプライベートキー JWT クライアント認証のために ID プロバイダーが必要とする同じ署名アルゴリズムを使用して設定します。 -
AgentCore Identity がmachine-to-machine (M2M)、on-behalf-of (OBO)、または認可コードフローのトークンを必要とする場合、短期間の JWT クライアントアサーションを構築します。アサーションには、ID プロバイダーに必要なクレームが含まれます。
-
AgentCoreアイデンティティは、提供された非対称署名キー ARN AWS を使用して、KMS を使用してアサーションに署名します。
-
署名付きアサーションは、
client_assertionと同様にトークンエンドポイントに送信されますclient_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer。 -
認可サーバーは、登録したパブリックキーに対するアサーションを検証し、リクエストされたトークンを発行します。
プライベートキー JWT は、カスタム OAuth 2.0 認証情報プロバイダー (CustomOauth2) で使用できます。これは、クライアント認証情報 (M2M)、JWT 認可許可 (OBO) とのトークン交換、認可コード (ユーザー委任アクセス) のすべての許可フローで機能します。
AgentCore ID でのプライベートキー JWT の設定
認証情報プロバイダーを正常に設定するには、まず、署名アルゴリズム、パブリックキー、必要な JWT クライアントアサーションクレームなど、プライベートキー JWT クライアント認証に関する ID プロバイダーの要件を確認します。
署名アルゴリズム
ID プロバイダーがプライベートキー JWT クライアント認証に必要とする署名アルゴリズムを特定します。これは、OAuth 2.0 カスタム認証情報プロバイダーの作成または更新privateKeyJwtConfig中の の signingAlgorithmフィールドに対応します。
-
AgentCore Identity で認証情報プロバイダーを作成するときに、署名アルゴリズムと同じアルゴリズムを指定します。
-
この署名アルゴリズムは、以下に詳述する許容可能な KMS キー仕様を選択するためにも使用されます。
AWS KMS 非対称キー設定
ID プロバイダーが署名キーを管理する方法を決定します。
-
ID プロバイダーがアップロードされたパブリックキーを受け入れる場合は、
SIGN_VERIFYを使用して非対称 KMS キーペアを作成します。署名アルゴリズムをサポートするキー仕様を選択します (次の表を参照)。キーは、認証情報プロバイダーと同じリージョンにある必要があります。AgentCore Identity で認証情報プロバイダーを作成するときに、KMS キー ARN を指定します。作成後、kms:GetPublicKey API を使用して対応するパブリックキーを生成します。 は、DER エンコードされた X.509 パブリックキーまたは SPKI
kms:GetPublicKeyを返します。一部の ID プロバイダーでは、これらのパブリックキーを特定の形式で要求しています。たとえば、Microsoft Entra には X.509 証明書オブジェクトが必要で、Okta には JSON ウェブキーが必要で、Ping Identity は両方をサポートしています。パブリックキーを ID プロバイダーに必要な形式に変換し、ID プロバイダーにアップロードします。 -
ID プロバイダーがキーペアを作成し、プライベートキーマテリアルを提供する場合は、
SIGN_VERIFYを使用して KMS キーにインポートします。署名アルゴリズムと互換性のあるキー仕様を選択します (次の表を参照)。手順については、「KMS AWS キーのキーマテリアルのインポート」を参照してください。AgentCore Identity で認証情報プロバイダーを作成するときに、KMS キー ARN を指定します。
signingAlgorithm 選択した によって、受け入れられる KMS キー仕様が決まります。
| 署名アルゴリズム | 許可された KMS キー仕様 |
|---|---|
|
|
|
|
|
|
|
|
|
AWS KMS キーポリシー
プライベートキー JWT に非対称 KMS 署名キーを使用するには、エージェントAgentCore ID がユーザーに代わって署名およびキー記述オペレーションを実行できるようにする必要があります。KMS キーのキーポリシーに次のアクセス許可を追加します。
このkms:ViaService条件により、リクエストが Amazon Bedrock AgentCore Identity を介して発信された場合にのみキーを使用できます。クロスアカウントキーは、キーポリシーが kms:DescribeKeyおよび kms:Signを呼び出し元の ID に付与するときにサポートされます。Principal ARN を AgentCore Identity を呼び出すアカウントのルート ARN に置き換えます。
{ "Id": "identity-service-cmk-policy", "Version": "2012-10-17", "Statement": [ { "Sid": "BedrockAgentCoreIdentityPrivateKeyJwtAccess", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "kms:Sign", "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" }, "StringLike": { "kms:ViaService": "bedrock-agentcore-identity.*.amazonaws.com" } } } ] }
クロスリージョンキーはサポートされていません。KMS キーは、認証情報プロバイダーと同じ AWS リージョンに存在する必要があります。
JWT クライアントアサーションの追加クレーム
ID プロバイダーが JWT クライアントアサーションヘッダーまたはプライベートキー JWT クライアント認証のペイロードで追加のクレームを必要とするかどうかを確認します。その場合は、 内の additionalHeaderClaimsおよび additionalPayloadClaimsフィールドにそれらを含めますprivateKeyJwtConfig。
-
の場合
additionalHeaderClaims、クレームalgまたは は許可されませんtyp。 -
の場合
additionalPayloadClaims、クレームiss、、sub、jti、exp、iatまたは は許可されませんnbf。audクレームの上書きを許可します (デフォルトでは ID プロバイダーのトークンエンドポイント)。
プライベートキー JWT 認証を使用してカスタムプロバイダーで OAuth クライアントを設定する
プライベートキー JWT クライアント認証を使用して認証情報プロバイダーを設定するには、 AWS コンソールで、「カスタムプロバイダーを使用して OAuth クライアントを追加する」を参照してください。 AWS CLI を使用して認証情報プロバイダーを設定することもできます。
CLI の例: Microsoft 認証情報プロバイダーのプライベートキー JWT
aws bedrock-agentcore-control create-oauth2-credential-provider \ --cli-input-json '{ "name": "microsoft-private-key-jwt", "credentialProviderVendor": "CustomOauth2", "oauth2ProviderConfigInput": { "customOauth2ProviderConfig": { "oauthDiscovery": { "discoveryUrl": "https://login.microsoftonline.com/your-tenant-id/v2.0/.well-known/openid-configuration" }, "clientId": "your-client-id", "clientAuthenticationMethod": "PRIVATE_KEY_JWT", "privateKeyJwtConfig": { "privateKeySource": { "kmsKeySource": { "kmsKeyArn": "arn:aws:kms:us-east-1:111122223333:key/your-key-id" } }, "signingAlgorithm": "PS256", "additionalHeaderClaims": { "x5t#S256": "Base64url-encoded SHA-256 thumbprint of the DER encoding of the X.509 public key certificate uploaded to Microsoft Entra" }, "additionalPayloadClaims": { "aud": "https://login.microsoftonline.com/your-tenant-id/oauth2/v2.0/token" } } } } }'
CLI の例: トークン交換On-behalf-ofを使用する Okta 認証情報プロバイダーのプライベートキー JWT
aws bedrock-agentcore-control create-oauth2-credential-provider \ --cli-input-json '{ "name": "okta-private-key-jwt", "credentialProviderVendor": "CustomOauth2", "oauth2ProviderConfigInput": { "customOauth2ProviderConfig": { "oauthDiscovery": { "discoveryUrl": "https://your-app.okta.com/oauth2/default/.well-known/openid-configuration" }, "clientId": "your-client-id", "clientAuthenticationMethod": "PRIVATE_KEY_JWT", "privateKeyJwtConfig": { "privateKeySource": { "kmsKeySource": { "kmsKeyArn": "arn:aws:kms:us-east-1:111122223333:key/your-key-id" } }, "signingAlgorithm": "RS256" }, "onBehalfOfTokenExchangeConfig": { "grantType": "TOKEN_EXCHANGE", "tokenExchangeGrantTypeConfig": { "actorTokenContent": "NONE" } } } } }'
プライベートキー JWT 認証を使用するカスタムプロバイダーを持つ OAuth クライアントのパラメータ
| [Parameter] (パラメータ) | [Required] (必須) | 説明 |
|---|---|---|
|
|
はい |
|
|
|
はい |
ID プロバイダーに登録されているクライアント識別子。 |
|
|
はい |
非対称 KMS 署名キーの完全な ARN。認証情報プロバイダーと同じリージョンに存在する必要があります。クロスアカウントがサポートされています。 |
|
|
はい |
JWT に署名するためのアルゴリズム。次のいずれか: |
|
|
いいえ |
追加の JWT ヘッダークレーム (マップ、最大 10 エントリ)。これを使用して、ID プロバイダーに登録 |
|
|
いいえ |
追加の JWT ペイロードクレーム (マップ、最大 10 エントリ)。 |
|
|
不要 |
プライベートキー JWT を使用する場合は を省略します。 |