This field-guide entry has not been reviewed in its new form yet. The studies are summarized as published; no review date is implied.
Key findings #
RFC 8693 lets a client present a security token to an OAuth 2.0 authorization server acting as a Security Token Service and receive a new token, for example one scoped more narrowly for a downstream service.
In the Agentic Identity Broker, an MCP gateway exchanges the agent’s token for the matching provider token through RFC 8693 on each tool call, so the provider token never reaches the agent.
RFC 8693 warns that without client authentication at the token endpoint, anyone holding a compromised token can trade it for other tokens.
In a JWT issued through token exchange, access control decisions must consider only the top-level claims and the current actor named in the act claim, while nested prior actors are informational.
A token exchange creates no tight link between the input and output tokens, so passing revocation from one to the other depends on the implementation and isn’t a property of the protocol.
Evidence #
| Study | Year | Sample | Method | Finding |
|---|---|---|---|---|
| OAuth 2.0 Token Exchange (RFC 8693)IETF | 2020 | n/a | Specification | Defines the token exchange grant, its request and response parameters, and the act and may_act claims. |
| Resource Indicators for OAuth 2.0 (RFC 8707)IETF | 2020 | n/a | Specification | Defines the resource parameter that tells the authorization server where a token will be used. |
| What I Learned Building an Identity Broker With Coding Agentsthis site | 2026 | n/a | Field report | Describes how a gateway exchanges the agent’s token for the matching provider token on each tool call. |
| Economies of Scale for MCP and Agentsthis site | 2026 | n/a | Talk | Presents the broker’s delegation model at AGNTCon + MCPCon Europe 2026. |
What to do #
For engineers #
Put the exchange in a component the agent can’t control, such as a gateway, and authenticate that component at the token endpoint. Name the target with resource or audience and ask for the smallest scope the tool call needs. RFC 8693 points out that broad requests across many target services are more likely to be refused.
Treat revocation as your own job. The RFC leaves it to the implementation whether revoking a grant or an input token affects tokens already issued, so keep issued tokens short-lived and check the grant at exchange time. Consent and revocation covers the rest.
If an agent’s token can travel further, use the act claim to record the agent as the actor and the may_act claim to state who may act for the subject.
For product and UX #
Users don’t see the exchange, but they see its effects. When a tool call fails because a grant expired or was revoked, tell the user which service and which agent were affected and how to grant access again.
How it works #
RFC 8693 defines the exchange as 1 request and 1 response at an authorization server’s token endpoint. With a gateway between an agent and its tools, the exchange runs like this:
Step through the exchange
- The agent calls a tool through the gateway and presents its own token.
- The gateway acts as the RFC 8693 client. It sends a
POSTto the token endpoint withgrant_type=urn:ietf:params:oauth:grant-type:token-exchange, asubject_tokenthat represents the person on whose behalf the request is made, and itssubject_token_type. Optional parameters name the target (resource,audience), the access wanted (scope), and the token type wanted (requested_token_type). - The gateway authenticates with the normal OAuth 2.0 client authentication methods.
- The authorization server validates the presented tokens and decides by policy whether to issue a token for the named target. If it refuses, it answers with
invalid_request, or withinvalid_targetwhen it won’t issue a token for the requested target. - A successful response is a normal OAuth token response:
access_tokencarries the issued token, together withissued_token_type,token_type, and, as recommended,expires_in. The issued token doesn’t have to be an OAuth access token. - The gateway calls the target service with the issued token and returns only the result to the agent.
The following request shows step 2 with placeholder hosts and tokens. It illustrates the RFC parameters and isn’t the broker’s API. I’ve left the values unencoded and added line breaks for readability; a real request URL-encodes the form body.
POST /token HTTP/1.1
Host: broker.example.com
Authorization: Basic <gateway client credentials>
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<token the agent presented>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://api.provider.example/
&scope=<permissions the tool call needs>The Agentic Identity Broker that Magnus Jungsbluth and I built uses this pattern, as I describe in the retrospective. A user grants an agent access to a service, such as GitHub, with a chosen permission set and an optional expiry, and the broker stores the provider tokens encrypted. On each tool call, an MCP gateway such as agentgateway exchanges the agent’s token for the matching provider token, so the provider token never reaches the agent.
RFC 8693 also defines an optional actor_token for the party that will act on behalf of the subject. In the issued JWT, the act claim can record that actor, and nested act claims record a chain of earlier actors. The broker roadmap lists token exchange for agent-to-agent calls as planned work.