OAuth token exchange for agent delegation (RFC 8693)

The control gap

An agent acting for a person needs authority at a service the person can reach. The tempting answers are both bad: reuse the user's token, which spreads a broad credential across every hop, or give the agent a service account, which erases the person entirely and makes every action look like the platform did it. Token exchange is the standardised third answer, and it is under-used because the request shape is unfamiliar rather than because it is hard.

What good looks like

Each hop holds a token scoped to that hop, with the human recorded as the subject and the agent recorded as the actor, so an action can be attributed to both.

• Exchange rather than forward. The downstream token has a different audience, a narrower scope, and a shorter life than the one presented.
• Preserve the delegation chain in the token, with the user as subject and the agent as actor, rather than flattening to one identity.
• Bind the exchanged token to the specific downstream resource, so it cannot be replayed at a sibling service.
• Keep exchange lifetimes short. The token exists to complete one task, not to be cached for the agent's lifetime.

A production workflow

1. The agent presents its own credential plus the user's token to the token endpoint with the exchange grant type.
2. The authorization server validates both, applies policy about what this agent may request for this user, and mints a downstream token.
3. The agent calls the downstream service with the exchanged token only.
4. The downstream service reads subject and actor from the token and records both against the action.

Copy this

The grant type is the long URN, which is the part most often mistyped. The response looks like an ordinary token response with one extra field.

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<the user's token>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=<the agent's own token>
&actor_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https%3A%2F%2Fapi.internal%2Fbilling
&scope=refunds:write
&requested_token_type=urn:ietf:params:oauth:token-type:access_token

HTTP/1.1 200 OK
{
  "access_token": "...",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 300
}

# The claims that make the result auditable downstream
{
  "sub": "user:alice",                  # the human the action is for
  "act": { "sub": "agent:refund-bot" }, # the agent doing it
  "aud": "https://api.internal/billing",
  "scope": "refunds:write",
  "exp": <five minutes out>
}

The act claim is what distinguishes delegation from impersonation. Without it the downstream service sees only the user, and an incident review cannot tell a person's own action from an agent's.

Evidence to require

• Every exchange, with the subject, the actor, the requested resource, and the granted scope.
• Exchanges refused because the agent was not permitted to act for that user or that resource.
• Downstream actions carrying both subject and actor claims, matched to the exchange that produced them.
• Token lifetimes actually issued, compared with the policy maximum.

Buyer checklist

• Does any service currently receive a token that was minted for a different audience?
• Can an incident reviewer distinguish an action the user took from one an agent took for them?
• What is the maximum lifetime for an exchanged token, and is it enforced or configured per client?
• Which agents may request exchange for which users, and where is that rule written?