What is Amazon Bedrock AgentCore Identity

Amazon Bedrock AgentCore Identity is an identity and credential management service designed for AI agents and automated workloads. The agent ID is implemented as a workload identity, maintaining compatibility with industry-standard workload identity patterns while possessing special attributes that provide agent-specific functionality. This service is natively integrated with Amazon Bedrock AgentCore, providing authentication, authorization, and credential management when agents or tools access AWS resources or third-party services on behalf of users (source: AWS Official Documentation).

Challenges Solved by Private Key JWT

According to the AWS ML blog, Amazon Bedrock AgentCore Identity now supports Private Key JWT client authentication for agents. Previously, agents used shared OAuth 2.0 client secrets to authenticate with downstream ID providers’ token endpoints. In contrast, Private Key JWT client authentication uses a signed JSON Web Token (JWT) client assertion for authentication (source: AWS Machine Learning Blog).

While the public key is registered with the ID provider, the corresponding private key is kept in AWS Key Management Service (AWS KMS). The official AgentCore Identity documentation explains that this approach “eliminates the shared secret between AgentCore Identity and the authorization server, replacing it with an asymmetric key pair that the customer fully controls.” Authentication is performed using a JWT client assertion compliant with RFC 7523 Section 2.2, which replaces the client secret (source: Private Key JWT client authentication - Amazon Bedrock AgentCore).

How Authentication Flow Works

The AWS ML blog illustrates the request flow using an example where a customer support agent reads a customer’s order history from an internal order API.

  1. The agent calls AgentCore Identity’s GetResourceOauth2Token to request a token for the order API.
  2. AgentCore Identity reads the client ID, KMS key ARN, and signing algorithm from the credential provider, constructs a short-lived JWT client assertion with the necessary payload claims (including key identifiers and certificate thumbprints, as well as any additional headers or payload claims configured), and signs it using the KMS asymmetric signing key with the configured signing algorithm (RS256, PS256, or ES256).
  3. AWS KMS signs the assertion and returns the signature result to AgentCore Identity without exposing the private key.
  4. AgentCore Identity posts the signed assertion to the ID provider’s token endpoint with grant_type=client_credentials and client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
  5. The ID provider verifies the signature against the registered public key and returns an access token to AgentCore Identity.
  6. AgentCore Identity returns the access token to the agent.
  7. The agent uses the access token to call the order API.
  8. The order API returns the customer’s order history.

The key difference between this flow and the shared secret approach is that the private key never leaves KMS (source: AWS Machine Learning Blog).

Supported Authorization Flows

Private Key JWT authentication works with three types of grant flows. The AWS official documentation categorizes these as client credentials (M2M), JWT authorization grant for token exchange (OBO), and authorization code (user-delegated access) (source: Private Key JWT client authentication - Amazon Bedrock AgentCore).

  • Machine-to-machine (M2M): The agent acts on its own behalf without human user intervention, using the client_credentials grant. The token subject is the client itself.
  • On-behalf-of (OBO): The agent acts on behalf of a specific user, using an existing token for that user. The user has already signed in somewhere, and an inbound user token exists. AgentCore Identity maintains client authentication via client assertion while exchanging the inbound user token for a downstream token.
  • Authorization code (user-delegated access): In addition to the above two flows, Private Key JWT client authentication supports all three grant flows on a custom OAuth 2.0 credential provider (CustomOauth2).

Setup Procedure and KMS Key Preparation

To properly configure the credential provider, first verify the ID provider’s requirements for Private Key JWT client authentication, including the signing algorithm, public key, and mandatory JWT client assertion claims. The signing algorithm corresponds to the signingAlgorithm field in privateKeyJwtConfig, which is specified when creating or updating an OAuth 2.0 custom credential provider (source: Private Key JWT client authentication - Amazon Bedrock AgentCore).

If the ID provider accepts uploaded public keys, create an asymmetric KMS key pair for SIGN_VERIFY purposes. The key must exist in the same region as the credential provider, and its KMS key ARN is specified when creating the credential provider. After creation, use the kms:GetPublicKey API to generate the corresponding public key. This API returns a DER-encoded X.509 public key or an SPKI, depending on the format required by the ID provider, as illustrated in the official documentation:

  • Microsoft Entra: Requires an X.509 certificate object
  • Okta: Requires a JSON Web Key
  • Ping Identity: Supports both formats

Another document explains that specifying PRIVATE_KEY_JWT as the client authentication method in the credential provider settings allows the use of an AWS KMS key for

Summary

Amazon Bedrock AgentCore Identity provides a robust identity and credential management service for AI agents and automated workloads, supporting Private Key JWT client authentication for secure and efficient authentication flows. By understanding the challenges solved by Private Key JWT, the authentication flow, supported authorization flows, and setup procedures, developers can effectively utilize this service to enhance the security and functionality of their applications.