Amazon Cognito OAuth Token Exchange (November 2026): What Startups Need to Know

What did the vendor release?

On 12 November 2026, AWS announced OAuth 2.0 token exchange support in Amazon Cognito. The feature implements RFC 8693 and addresses a common problem in applications with multiple services: how one service can call another on behalf of a signed-in user without simply passing along the user's original token.

Previously, a service making that downstream call had to forward the original user token or build and maintain its own token minting logic. Cognito now provides a token exchange mechanism for that workflow.

The new token can have a narrower scope than the original token. It can also be bound to a single audience and issued without a refresh token. These properties let applications request credentials intended for a specific downstream service rather than automatically passing the original token through the chain.

Cognito also supports an optional actor token. When an actor token is included, Cognito adds an act claim identifying the intermediary. This helps a downstream service distinguish a request made directly by the user from one made by an agent acting on that user's behalf.

AWS gives an example involving a Model Context Protocol (MCP) server. The MCP server exchanges a user's token for a narrowly scoped token to call a backend API. The resulting actor claim identifies the MCP server.

Developers can perform token exchange through the Cognito token endpoint or the new GetDerivedToken API. AWS says the feature is available on the Essentials and Plus plans in every AWS Region where Cognito is available.

Which startups are affected?

This change matters most to startups where a signed-in user's request crosses service boundaries. The relevant pattern is not simply having a login page. It is having a service or AI agent that needs to call another service on the user's behalf.

For example, consider an application that accepts a user request, passes it to an intermediary service, and then calls a backend API. That architecture is a candidate for reviewing token exchange. The intermediary can request a token for the downstream audience instead of forwarding the original user token.

AI agent and MCP integrations are especially relevant because AWS explicitly describes agent-to-backend delegation as a use case. However, the announcement also covers ordinary services acting on behalf of users.

Our recommendation: Put applications into two groups. First, identify services and agents that pass user tokens to downstream APIs or maintain custom token minting code. Review those integrations first. Second, identify applications that do not delegate access across services. Do not schedule migration work for the second group solely because Cognito has gained this feature.

Adopt it or keep the existing approach?

There is a useful distinction between feature availability and a reason to migrate. AWS has provided a new option. The announcement does not establish that every existing Cognito integration needs to change.

For applications that forward original tokens across service boundaries, token exchange offers an alternative based on narrower scopes and a single audience. For applications with custom token minting logic, it offers a Cognito-managed token exchange path worth evaluating.

Our recommendation: Prefer a small adoption pilot when downstream delegation is part of the architecture. Choose one intermediary and one backend API. Define the intended audience, permissions and actor identity before changing the application. Compare the resulting access against the existing approach.

Keep the current approach temporarily if the downstream authorization design has not been reviewed or the application cannot yet validate the derived token correctly. Avoid replacing working authentication code with an untested delegation flow.

Our recommendation: Treat the actor claim as part of the authorization design, not just additional logging information. Decide whether a backend must distinguish direct user access from intermediary access. Document how that distinction should affect permitted operations.

What to check before enabling it?

Start with eligibility. AWS states that token exchange is available on the Cognito Essentials and Plus feature plans in supported Cognito Regions. Confirm that the relevant user pool and application setup can use the feature before planning implementation.

Next, inspect the actual delegation path. Identify the original user token, the intermediary, the downstream audience and the permissions the downstream service requires. This makes it possible to define what narrower access should mean for the application.

Our recommendation: Test whether the derived token contains only the intended scope and audience. Confirm the downstream API rejects tokens that should not be accepted. Check that the integration does not depend on receiving a refresh token with the derived credential.

If the workflow uses an actor token, inspect the resulting act claim. Confirm that the downstream service interprets the intermediary identity as intended. Include both direct-user and delegated-request cases in the test plan.

Finally, choose between the token endpoint and GetDerivedToken based on the application integration. Test error handling and preserve a rollback path before changing production traffic.

Our recommendation: Make the release decision on demonstrated permission boundaries, not on feature availability alone. A successful pilot should show that a delegated service receives the access it needs without unnecessarily carrying the original user's broader authority.