OAuth token exchange solves a narrow but important problem: one service has a security token, yet the next service should receive a different credential with a different audience, scope or actor. RFC 8693 defines the request and response for that exchange. It also makes a distinction that architecture diagrams often blur—impersonation and delegation are not the same.

In impersonation, the new token represents the subject as if that subject were acting directly. In delegation, the new token represents an actor operating on behalf of a subject. The downstream authorization decision may need both identities.

Why forwarding the original token is risky

A front-end API often calls several internal services. Simply forwarding the user’s original bearer token is convenient, but it can give the downstream service a credential intended for another audience or carrying more scope than it needs.

It also obscures the service that made the call. The downstream log may show only the user, even though a scheduler, support tool or workflow engine chose the action.

Token exchange lets the intermediary present a subject token to an authorization server and request a new token appropriate for the next resource. The authorization server can apply policy, narrow the audience and scope, and preserve the actor relationship when required.

Subject token and actor token answer different questions

RFC 8693 names the token representing the primary identity the subject_token. An optional actor_token can identify the party acting on behalf of that subject.

A payroll workflow offers a simple example:

  • the employee is the subject;
  • the approved payroll service is the actor;
  • the downstream payment API is the target resource;
  • the exchanged token should authorize only the operation the payment API needs.

The payment API may need to know both that the employee’s data is involved and that the payroll service initiated the request. Dropping either side can break authorization or audit evidence.

Impersonation changes who the token presents

In an impersonation case, the requesting party asks for a token that represents the subject without preserving a separate actor in the resulting identity. The downstream system evaluates the subject as the current principal.

That can be legitimate—for example, a tightly controlled compatibility boundary where an older service understands only end-user identity. It also removes context. If the actual caller matters for approvals, rate limits or investigations, pure impersonation can be too lossy.

Do not infer impersonation merely because a service-to-service call contains a user ID. Define it as an explicit policy outcome from the authorization server.

Delegation preserves the actor chain

Delegation says that one party is acting on behalf of another. RFC 8693 describes the act claim for expressing the current actor and, when needed, a chain of prior actors.

The chain should be treated as evidence, not as a list of identities whose permissions are automatically combined. RFC 8693 notes that a resource server generally considers the current actor when making access-control decisions; prior actors can still matter for policy and audit.

Keep the chain short and useful. A dozen internal hops copied into every token increases disclosure and makes logs harder to interpret. Where a full trace belongs in an audit system, the token can carry a correlation identifier instead of every operational detail.

Narrow the audience and scope at each hop

The exchange request can name the desired resource, audience and scope. The authorization server decides what is allowed; the client does not grant itself new rights by asking.

The returned token should be no broader than the downstream call requires. A reporting service exchanging a user token for a billing API does not need administrative billing scope simply because the original user is an administrator elsewhere.

This is also an audience boundary. The new token should be valid at the intended service, not at every internal API. Our guide to JWT access token validation covers the checks the receiving API must perform.

Do not treat exchange as validation

The authorization server must validate the input tokens and the client making the exchange. The downstream resource must still validate the output token. Token exchange is a protocol for obtaining another token, not a signal that every participant can skip its normal checks.

A sound exchange policy considers:

  • which clients may exchange which token types;
  • which issuers and audiences are trusted;
  • whether an actor token is required;
  • which target resources can be requested;
  • the maximum resulting scope;
  • whether impersonation is allowed at all;
  • how actor chains are represented and limited;
  • lifetime and revocation behavior;
  • what evidence is logged.

Reject an unknown target instead of falling back to a broad default token.

Make the audit record explicit

For a successful exchange, record the client, subject reference, current actor, requested target, granted audience, granted scope, policy version, time and correlation ID. Do not log the bearer tokens.

For a downstream action, preserve enough of that context to answer three questions later: whose data or authority was involved, which service performed the action, and which policy allowed it.

This is where delegation earns its complexity. A downstream charge should not look as though the customer personally called an internal endpoint when a scheduled service actually did.

Test the denial paths

A useful test matrix includes:

  • a valid subject token from an untrusted issuer;
  • a client that is not allowed to exchange tokens;
  • a requested audience outside the original grant;
  • a broader scope than policy permits;
  • delegation without the required actor token;
  • impersonation requested where only delegation is allowed;
  • an actor chain that exceeds the configured depth;
  • a returned token presented to the wrong resource;
  • a revoked or expired input token;
  • an unavailable authorization server during a downstream call.

Decide which failures can be retried and which require new user authorization. A generic retry loop should not turn a policy denial into repeated traffic.

Source and version note

Checked 27 October 2026 against RFC 8693: OAuth 2.0 Token Exchange, published January 2020. The RFC defines the exchange protocol and token semantics; deployment policy, product permissions and audit retention remain system-specific.