How to handle token audience changes when an AI agent acts on behalf of a user?

FASupportBot — Invalid Date

OAuth 2.0 Token Exchange (RFC 8693) is indeed designed for this kind of scenario. It allows you to exchange an existing token (the user's web-audience token) for a new token with a different audience (e.g. mcp) while maintaining the user's identity and authorization context.

Important Note: FusionAuth does not currently implement RFC 8693 (OAuth 2.0 Token Exchange) natively. There is an open GitHub issue tracking this feature request. However, FusionAuth provides alternative approaches to achieve similar outcomes.

How Token Exchange Works (RFC 8693 Concept) User authenticates and receives a token with audience: web. AI agent receives a request from the user via the chat interface. Agent exchanges the token: The agent (or a backend service acting on its behalf) calls the token exchange endpoint, providing: The original web-audience token as the subject_token The desired new audience (mcp) in the audience parameter Optionally, a narrower set of scopes if the downstream service requires fewer permissions New token issued: The authorization server returns a new token with audience: mcp, tied to the same user identity. Agent calls downstream service using the new token. Example Token Exchange Request POST /oauth2/token Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:token-exchange &subject_token= &subject_token_type=urn:ietf:params:oauth:token-type:access_token &audience=mcp &scope=mcp:read mcp:write Current Alternatives in FusionAuth

Since RFC 8693 isn't supported yet, here are the recommended approaches:

1. Issue a JWT API

Use the Issue a JWT endpoint to exchange a token from one application for a token for another application. This is FusionAuth's implementation of SSO for access tokens:

GET /api/jwt/issue?applicationId={targetApplicationId} Authorization: Bearer

This returns a new JWT with the target application's audience, preserving the user's identity. The user must be registered in both applications.

2. JWT Populate Lambda

Use a JWT Populate Lambda to customize the aud claim directly. You can add multiple audiences to avoid token swapping:

function populate(jwt, user, registration) { // Add multiple audiences jwt.aud = ['web', 'mcp', 'https://api.example.com']; } 3. Vend a JWT API

For more complex delegation scenarios, use the Vend a JWT endpoint to create a custom JWT with free-form claims (except reserved claims like iat, exp, amr, and cnf).

Key Considerations Authorization: The agent should be a registered OAuth client with permission to perform token exchanges. You may want to restrict which clients can exchange tokens and for which audiences. Scope narrowing: The new token can have a subset of the original token's scopes, ensuring least-privilege access to the downstream service. User consent: Depending on your security requirements, you may want to prompt the user to authorize the agent's access to the downstream service the first time this exchange happens. Application registration: When using the Issue JWT approach, ensure the user is registered in both the source and target applications.

This approach avoids re-authentication and cleanly separates concerns: the user holds their web token, and the agent dynamically obtains the correct token for each downstream service it needs to call.

Related Documentation OAuth 2.0 Grant Types - Token Exchange Grant - Overview of RFC 8693 token exchange Issue a JWT API - Exchange tokens between applications (FusionAuth's current solution) Vend a JWT API - Create custom JWTs for complex scenarios JWT Populate Lambda - Customize JWT claims including audience GitHub Issue #1471 - Track RFC 8693 implementation progress

Does FusionAuth support RFC 8693 token exchange for impersonation use cases?

FASupportBot — Invalid Date

Based on my research of the FusionAuth documentation, I need to provide an important correction to the draft answer. FusionAuth does not currently support RFC 8693 token exchange natively. Here's the improved answer:

Answer

Important Clarification: FusionAuth does not currently support RFC 8693 token exchange natively. The draft answer contains inaccurate information that needs correction.

Current RFC 8693 Status:

Native RFC 8693 token exchange is not implemented in FusionAuth There is an open GitHub issue (#1471) tracking this feature request for implementing impersonation and delegation tokens according to RFC 8693 No confirmed ETA is available for this feature

Workarounds for Token Exchange and Impersonation:

While native RFC 8693 support is unavailable, FusionAuth offers alternative approaches:

1. Vend JWT API for Delegation

You can use FusionAuth's Vend a JWT endpoint to create custom tokens that include an act claim, following RFC 8693 delegation chain semantics:

const response = await client.vendJWT({ keyId: 'your-signing-key-id', timeToLiveInSeconds: 300, claims: { sub: 'coordinator-agent-entity-id', act: { sub: 'original-human-user-id' }, permissions: ['read:documents'] } });

This approach provides delegation semantics where the original actor is tracked in the act claim.

2. Impersonation Implementation

For pure impersonation (without delegation tracking), you can implement this at the API level:

Create a backend endpoint (e.g., /api/impersonate/{id}) that verifies the requesting user is an admin Use the Vend JWT API to directly construct a token for the target user Manage the impersonated session in your application

Note: Impersonation via the OAuth/OIDC workflow is not supported as it would conflict with the OAuth specification.

3. Other Alternatives Consolidate services under a single application registration Alter the aud claim via a JWT lambda Pass two separate JWTs in different headers (one for the service, one for the user)

Recommendation:
If standards-compliant RFC 8693 token exchange is a hard requirement for your migration, you may want to track or upvote the GitHub issue mentioned above. For immediate needs, evaluate whether the Vend JWT API workaround meets your delegation or impersonation requirements.

Related Documentation Vend a JWT API - API for creating custom JWTs with specified claims OAuth 2.0 Grant Types - Token Exchange Grant - Overview of RFC 8693 token exchange concept GitHub Issue #1471: Implement Impersonation and Delegation Tokens (RFC 8693) - Open feature request Forum: Does Fusionauth have an "impersonation" feature? - Community discussion on impersonation approaches Forum: Does FusionAuth Support UMA Grant and Token Exchange (RFC 8693)? - Related community discussion

Topics tagged with token-exchange

How to handle token audience changes when an AI agent acts on behalf of a user?

Does FusionAuth support RFC 8693 token exchange for impersonation use cases?