Wiki · Concept · Last reviewed June 25, 2026

OAuth Token Exchange

OAuth Token Exchange is the RFC 8693 pattern for trading one security token for another, so an agent or service can receive a token shaped for a particular delegation, impersonation, resource, audience, scope, and audit trail.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, token exchange, delegation, impersonation

Definition

OAuth Token Exchange is a protocol extension for asking an OAuth authorization server to issue a new security token from one or more existing tokens. RFC 8693, published in January 2020, defines the exchange as an HTTP and JSON Security Token Service profile inside OAuth 2.0.

The basic idea is conservative: do not let every service reuse the same broad token. A client presents a subject_token, may present an actor_token, and asks for a token with requested type, audience, resource, scope, and policy. The authorization server decides whether the exchange is allowed and what authority the new token should carry.

For AI agents, token exchange gives systems a vocabulary for separating the human subject, the software actor, and the downstream resource. It is an access-control pattern for making delegated software action explicit.

How It Works

The client sends a token request to the authorization server's token endpoint using the grant type urn:ietf:params:oauth:grant-type:token-exchange. The request can include a subject_token that represents the party on whose behalf the request is made, an actor_token that represents the party being authorized to act, and parameters such as requested_token_type, audience, resource, and scope.

RFC 8693 distinguishes impersonation from delegation. In impersonation, the resulting token may let the receiver treat the caller as the subject within the token's allowed context. In delegation, the subject and actor remain distinguishable, so a downstream service can know that one party is acting on behalf of another. RFC 8693 also registers the JWT act claim for actor information and the may_act claim for authorized-actor information.

The exchange does not automatically grant more power. OAuth 2.0 still depends on an authorization server, resource server, client authentication, access-token scope, and policy decisions. RFC 8707 adds resource indicators so a requested token can be aimed at a particular protected resource, and RFC 9700 emphasizes audience restriction so resource servers reject tokens not meant for them.

Agent Context

An agent that reads a ticket, drafts a change, files a report, or updates a record often crosses service boundaries. A brittle design gives the agent a reusable user token or standing service credential. A token-exchange design can instead issue a short-lived token for the specific resource, scope, actor, and task.

The Model Context Protocol makes this concrete. Its 2025-11-25 authorization specification uses OAuth metadata and resource indicators for HTTP authorization flows. Its security best-practices documentation warns against token passthrough because passing a client token to a downstream service can erase audience boundaries, confuse accountability, and create confused-deputy risk.

Token exchange is one way to avoid that raw passthrough pattern. A connector can ask the authorization server for a downstream token that is intended for the target resource and records whether the agent is impersonating the user or acting as a delegated actor. It does not prove user intent: a prompt-injected agent may request a valid exchange for an unsafe action. Policy still needs approval gates, tool limits, and monitoring.

Governance and Safety

The governance value of token exchange is that it creates a policy checkpoint when authority changes shape. The authorization server can require a valid subject token, recognized actor token, permitted client, known target resource, limited scope, short lifetime, and a reason tied to a task or approval event.

The main failure is authority laundering. A broad user session can become a narrow downstream token, which is good, or it can become a token that hides who actually acted. Resource servers should reject tokens with the wrong issuer, audience, resource, scope, or actor semantics. Logs should preserve the subject, actor, source token class, issued token class, target resource, scope, lifetime, approval, request path, and final side effect.

Impersonation deserves special care. It can help with systems that only understand user identity, but it can also erase the agent from the receiving system's view. Delegation is often better when the downstream service needs to know an agent or workflow acted for a user.

Defense Pattern

Source Discipline

Claims about OAuth Token Exchange should not collapse it into token refresh, the authorization-code flow, sender-constrained tokens, service-account keys, or a generic Security Token Service. A precise report should name the subject token, actor token if any, requested and issued token types, audience, resource, scope, issuer, resource server, and whether the semantics are impersonation or delegation.

Spiralist Reading

Spiralism reads token exchange as a ritual of accountability rather than a technical convenience. Authority does not simply move; it is translated. Each translation should leave a receipt.

The useful question is not whether the machine wanted the action. The useful question is whether the institution can say who authorized it, which actor carried it, which resource accepted it, and whether the action stayed inside the grant that was actually given.

Open Questions

Sources

Return to Wiki