# Design Delegation Boundaries with OAuth Token Exchange > Give each downstream service a narrow token by separating subject, actor, audience, scope, lifetime, and audit context. Canonical URL: https://www.devobs.io/articles/oauth-token-exchange-delegation-boundaries/ By: Elias Brooks Published: 2023-04-23T11:38:29.549Z Updated: 2026-09-05 Section: Authorization Use OAuth token exchange when a service must call another service on a user's behalf but should not forward the original broad token. Exchange at each trust boundary for a token with one intended audience, the minimum scope, a short lifetime, and explicit subject and actor context. Delegation preserves whose authority is being exercised; impersonation changes which identity appears to act. ## Trace one call chain A browser calls the orders API with a token intended for that API. The orders API submits invoice generation to a worker, which calls the documents service. Forwarding the browser token to both services exposes it to recipients it was not intended for and may give the worker every scope the frontend received. Instead, the orders API presents the incoming token as the subject token and authenticates itself to the authorization server. It requests an exchanged token for the documents service with `invoice.render`. The worker receives only that token or exchanges again for its own audience. The documents service validates issuer, audience, expiry, scope, and any required actor chain. [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) defines OAuth 2.0 token exchange, including subject and actor tokens, requested token type, audience, resource, scope, and an `act` claim for actor information. The specification does not choose your delegation policy. The authorization server must decide which clients may exchange which subjects into which resources and scopes. ## Keep audience and scope separate Audience answers where the credential can be redeemed; scope answers what it permits there. [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707) defines resource indicators and explains audience restriction, including risks of tokens valid at multiple resources. Prefer one audience per downstream token. A multi-audience bearer token lets any intended recipient potentially replay it at another recipient and therefore assumes more trust. Downscope at every hop. The orders API may have `orders.read invoices.create`; the documents service needs only `invoice.render` on one job. Bind tenant and resource context through the authorization policy or a structured claim the resource server validates. Do not let a caller supply arbitrary actor, subject, or tenant claims. They come from validated input tokens and server-side policy. Keep lifetimes aligned with the task. A synchronous call can use a token lasting minutes. A queued job that may wait hours should not carry a long-lived bearer token in the message. Store the job's durable authorization context and exchange at execution using the worker's credential, rechecking whether policy allows continued delegation. Decide whether user revocation cancels queued work. ## Make impersonation visible Delegation means “worker W acted for user U.” Logs and audit records need both identities, the client that performed the exchange, source and target audiences, granted scope, tenant, resource, token ID or safe correlation, and policy decision. User-facing history should say that an automated service performed the action on their behalf. Impersonation may be appropriate for tightly governed support workflows, but it should be a different grant with stronger approval, limited actions, short expiry, and conspicuous audit. Do not erase the actor by issuing a token that contains only the user subject. The downstream service must be able to enforce rules that differ for direct user action and delegated automation. ## Test confused-deputy cases Attempt exchange for an unapproved audience, a broader scope, another tenant, another user's subject token, an expired token, and a token whose audience excludes the exchange endpoint. Try replaying the downstream token at the orders API. Verify queued work after membership revocation and ensure logs preserve the actor chain without storing raw tokens. The next step is to draw the token at each hop of one production call chain and remove every audience or scope the immediate receiver does not need. Review by 2026-12-05 or when the authorization-server policy changes. ## Source references - -