Implement OAuth 2.0 Token Exchange (RFC 8693) for delegation and impersonation scenarios
domain: identity-general · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Confirm your authorization server supports RFC 8693 token exchange and that your client is pre-authorized to perform exchanges.
POST to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:token-exchange, subject_token (the incoming token), subject_token_type (e.g., urn:ietf:params:oauth:token-type:access_token), and the desired requested_token_type.
For delegation, also supply an actor_token and actor_token_type identifying the service acting on behalf of the subject.
The authorization server validates both tokens, checks the may_act claim on the subject token to authorize the exchange, then issues a new token encoding both subject and actor claims.
Inspect the issued_token_type in the response to confirm the returned token type, then pass the new token to the downstream service.
Log the exchange event including subject, actor, and requested scopes for audit purposes.
Known gotchas
If the subject token does not contain a may_act claim granting the actor permission, well-implemented authorization servers will reject the exchange with an invalid_grant or access_denied error.
The returned composite token encodes both subject and actor identities; downstream resource servers must understand this structure or they will misidentify the effective principal.
Token exchange is not universally supported — verify your IdP's implementation against the RFC before relying on it, as vendor support and claim naming vary.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?