Amazon Bedrock AgentCore now supports OAuth 2.0 token exchange for multi-tenant agents, addressing identity challenges in agentic systems. This feature enables secure identity propagation across tenant boundaries by allowing agents to act on behalf of users without compromising security. The implementation follows the RFC 8693 token-exchange grant, ensuring standards-based interoperability with compatible authorization servers. The solution helps prevent the confused deputy problem, where downstream systems could be tricked into trusting an agent unconditionally. The implementation is demonstrated through a reference example using Okta and the TravelBot agent, which serves two example tenants (Acme and Globex). The reference implementation will be available in the aws-samples/sample-obo-flow-poc repository after publication. The OBO pattern is essential whenever an agent fronts multiple downstream services or tenants and the inbound token’s audience differs from any single downstream API. For a single-tenant agent where the inbound audience already matches the downstream service, direct token forwarding can be sufficient. The rest of this post focuses on the multi-tenant case. The implementation requires alignment across the agent runtime, the authorization servers, and the downstream APIs. When any one of them is misconfigured, the security posture degrades silently. Amazon Bedrock AgentCore Gateway and AgentCore Identity remove that coordination burden. The Gateway intercepts the tool call, identifies the target tenant, and instructs Identity to perform the exchange against the tenant’s authorization server before the downstream call is issued. The implementation also highlights the difference between impersonation and on-behalf-of token exchange. In an OBO exchange, the inbound token’s sub claim is preserved while the aud claim is rewritten to the downstream service. The actor of the exchange is recorded in a separate claim, so the downstream API can answer two questions from a single token: who is being acted on behalf of? and who is performing the action? Authorization decisions belong on sub. Audit logs and rate-limiting decisions belong on the actor. For a deeper conceptual treatment of impersonation versus on-behalf-of, refer to Apply fine-grained access control with Bedrock AgentCore Gateway interceptors. The following diagram contrasts the two patterns using TravelBot’s booking tools. In direct user-token forwarding, the inbound and downstream tokens are the same token. In OBO, each hop carries a distinct token bound to a different tenant’s booking API. Figure 1. Direct user-token forwarding vs. on-behalf-of token flow for TravelBot’s booking tools. In the direct-forwarding pattern (top), the agent forwards the user’s token unchanged. The token’s aud claim was issued for the agent’s API, so the downstream tools must either skip audience validation or accept whatever audience the upstream service hands them. Both options reintroduce the confused deputy. In the on-behalf-of pattern (bottom), AgentCore exchanges the token at each hop for a new token whose aud claim is bound to a single downstream service and whose scp is reduced to the minimum required. The sub claim is preserved across hops, so audit and authorization decisions still resolve to the original user, while the actor claim records AgentCore as the delegate that performed the exchange. Solution overview Throughout this post, the following identifiers refer to specific Okta resources in the TravelBot reference. Identifier Role TravelBot Provider Okta authorization server that issues the inbound JWT to the agent. ACME Travel API Okta authorization server that mints OBO tokens for the Acme tenant. Globex Travel API Okta authorization server that mints OBO tokens for the Globex tenant. TravelBot Agent Client Okta API Services app for the agent’s machine-to-machine path (legacy/testing). TravelBot User Client Okta OpenID Connect (OIDC) app for the 3-legged user login. AgentCore Delegate Okta app whose credentials AgentCore Identity uses to perform the token exchange. The TravelBot reference implementation uses Okta on both sides of the exchange. One Okta authorization server (TravelBot Provider) authenticates the agent. Two more (ACME Travel API and Globex Travel API) mint OBO tokens for each tenant. All three are Okta Custom authorization servers. Okta’s built-in Org authorization server does not support custom audiences or scopes and cannot serve this pattern. The same roles can be played by other identity providers (IdPs) with equivalent capabilities. Because RFC 8693 is implemented at the authorization-server layer, the same architecture should
Source: awsml
