OAuth Token Exchange Gains Traction as the Glue for Agentic Identity Systems

In modern distributed applications a single user authorisation often has to travel through dozens of services before the final operation is performed. Traditional OAuth grant types assume a one‑shot flow: a client obtains a token and uses it directly. That model breaks down when the token’s audience, scope, or format does not match the next hop. OAuth Token Exchange, defined in RFC 8693, fills that gap by allowing a service to present an existing token to the authorization server and receive a new token that is correctly scoped and addressed for the downstream request.

---

How the exchange works

1. POST to the token endpoint – The same endpoint used for the authorization‑code and client‑credentials flows.
2. Subject token – The existing credential (access token, ID token, JWT, SAML assertion, etc.) that identifies the party on whose behalf the new token is requested. The subject_token_type parameter tells the server how to parse it.
3. Optional modifiers
   • audience – Sets the aud claim of the issued token, binding it to a specific resource server.
   • scope – Requests a narrower set of permissions than the subject token provides.
   • actor_token – Supplies a second credential that identifies the calling service. Including this token switches the flow from impersonation to delegation.
   • requested_token_type – Indicates the desired format of the response (JWT, opaque token, etc.).
4. Response – The server returns the new credential in the access_token field, along with expires_in and optionally issued_token_type.

The exchange does not invalidate the subject token; revocation must be performed separately. Client authentication at the token endpoint is optional in the spec, but in practice most deployments require a confidential client to authenticate, otherwise any holder of a valid token could trade it for another one.

Impersonation vs. delegation

Aspect	Impersonation	Delegation
Token content	Only the original user (sub) is present.	Both sub (user) and act (acting service) claims are present.
Audit visibility	Logs look like a direct user action.	Logs show who authorized the request and which service executed it.
Typical use	Trusted internal service that should be invisible to downstream resources.	Multi‑agent workflows where each hop must be traceable.

The actor claim (act) is a JSON object embedded in the issued JWT. It can contain any attributes the resource server needs to make a decision (service name, client ID, etc.). The spec also defines an may_act claim that a subject token can carry to pre‑authorise specific actors. Enforcement of that claim is left to the implementation.

Core use cases

1. Microservice request chains

When a request passes through several backend services, the original token is often unsuitable for the next hop: its audience may be the first service, and it may contain more permissions than needed. By exchanging the token at each boundary, services receive a credential that is least‑privilege for the immediate downstream target while still preserving the original user identity.

2. AI agent delegation

An AI assistant that a user authorises can invoke a chain of tools (search, data store, model inference). Rather than re‑prompt the user at each step, the assistant exchanges its delegated token for a token scoped to each tool. Because the exchanged token carries both the user (sub) and the assistant (act), every tool can audit who asked for the operation and which agent performed it.

3. Cross‑domain federation

Enterprises often have multiple identity providers. A SAML assertion from an external IdP cannot be presented directly to a resource that only trusts the local OAuth server. The external assertion becomes the subject token; the local server validates it, maps it to a local principal, and issues a token in the local trust domain. This bridges the gap without requiring the user to log in again.

Why token exchange matters for agentic identity

Agentic systems rely on delegation: a user grants an agent permission, and that agent may spawn sub‑agents. Each hop needs a credential that:

• Identifies the original user.
• Identifies the current acting service.
• Is limited to the exact permissions required for the next call.

Token exchange provides a standardised, auditable way to achieve that. Because each token is issued with a specific audience and expiry, revoking the original user consent automatically stops further exchanges – downstream services will reject any token that cannot be validated against the current signing keys.

Security‑focused best practices

1. Scope reduction – Never allow an exchange to broaden scope. Most servers enforce this by default, but explicit policy is recommended.
2. Authenticate the client – Require confidential‑client authentication at the token endpoint. Anonymous exchanges open a path for token‑theft attacks.
3. Policy for multi‑hop delegation – Use the may_act claim to pre‑authorise which actors may exchange a token, and enforce scope reduction at each hop.
4. Revocation hygiene – After a successful exchange, decide whether the subject token should remain usable. If not, invoke the revocation endpoint immediately to avoid a window where two tokens with overlapping authority are active.
5. Prefer delegation for auditability – In any workflow where the request chain matters (e.g., compliance, debugging), include an actor token so the downstream service can see both sub and act.

Concrete example: Descope ↔ Skyflow token exchange

Descope’s OAuth 2.1 server exposes a token‑exchange endpoint as part of its Agentic Identity Hub. The flow looks like this:

1. A user logs in through Descope and receives an access token (sub=user‑123).
2. An AI agent, acting on behalf of the user, calls Descope’s /token endpoint with:
   • subject_token = the user’s access token
   • subject_token_type = urn:ietf:params:oauth:token-type:access_token
   • actor_token = the agent’s own client‑credentials token
   • audience = skyflow.api
   • scope = read:records
3. Descope validates both tokens, checks any may_act constraints, and issues a Skyflow‑compatible bearer token.
4. The Skyflow service validates the token, sees both the user identity and the agent identity, and enforces row‑level security based on the user’s role.

The exchange happens entirely server‑to‑server; no user interaction is required after the initial consent.

Looking ahead

As more applications adopt agentic identity – where autonomous services act on behalf of humans – the need for a reliable, standards‑based credential translation layer will only grow. OAuth Token Exchange offers a pragmatic solution: it preserves identity context, enforces least‑privilege at each hop, and produces an audit trail that can be consumed by security and compliance tooling.

Developers interested in trying it out can start with the open‑source reference implementation in the OAuth 2.0 Token Exchange spec repository and explore Descope’s documentation on token‑exchange integration.

---

Key take‑aways

• Token exchange trades an existing credential for a new one with a different audience, scope, or format.
• Impersonation hides the intermediate service; delegation makes it visible via the act claim.
• Use it to keep microservice chains, AI agents, and federated domains secure and auditable.
• Always authenticate the client and enforce scope reduction to maintain a strong security posture.