OAuth Token Exchange and Delegation Guide: RFC 8693 and On-Behalf-Of

When a service, workload or AI agent forwards the token it was given instead of exchanging it, every downstream API inherits a credential that was never meant for it and loses sight of who is really acting. OAuth token exchange (RFC 8693) and the on-behalf-of patterns built on it fix this by turning one token into another with a new audience, narrower scope and an explicit record of the acting party. This guide goes deeper than the overview: request parameters, subject and actor tokens, the act and may_act claims, delegation versus impersonation, downscoping, cross-domain chaining and the identity assertion authorization grant. It is written for identity architects, API platform teams and engineers building multi-service or agentic systems. For the wider picture see the OAuth 2.0 and OpenID Connect Guide.

Key takeaways

• Exchange, never forward. Each hop should present its own token, audience-restricted to the next resource, obtained from a security token service that applies policy.
• Delegation keeps two identities. With an actor token and an act claim the downstream API sees both the user and the service acting for them; impersonation erases the actor.
• Only the current actor counts. RFC 8693 says access control uses the top-level claims and the outermost act; nested actors are an audit trail, not an authorisation input.
• Downscope at every step. Use resource, audience and scope so each exchanged token carries less authority than the one it replaced, and refuse requests that try to widen it.
• The STS is a tier-zero system. It mints tokens for many audiences, so its client authentication, exchange policy and signing keys need the protection you give your identity provider.

What token exchange is and where the security token service fits

RFC 8693 defines a protocol for requesting a security token from an OAuth 2.0 authorization server acting as a security token service (STS), which the RFC describes as "a service capable of validating security tokens provided to it" and issuing new ones in response. The client presents an existing token (the subject token, optionally with an actor token) and asks for a different token: one for another audience, with fewer scopes, in another format, or recording delegation. The token exchange grant type is identified by grant_type=urn:ietf:params:oauth:grant-type:token-exchange at the ordinary token endpoint.

Three problems drive adoption.

• Audience mismatch: a token issued for API A should be rejected by API B. If A needs to call B, it must obtain a token for B, not forward its own. RFC 8707 notes that an audience-restricted token "cannot then be taken by that resource and presented elsewhere".
• Lost attribution: a middle tier calling with its own client credentials hides the user; forwarding the user token hides the middle tier. Token exchange can carry both.
• Federation boundaries: a workload holding a token from one issuer (a Kubernetes service account token, a CI job's OIDC token) needs a token another issuer accepts. This external token exchange underpins keyless workload federation.

The request and response in detail

The client sends an HTTP POST with form-encoded parameters. Client authentication is not mandated by the RFC, but its security considerations warn that "omitting client authentication allows for a compromised token to be leveraged via an STS into other tokens". Treat authenticated, confidential clients as a requirement for any exchange that crosses a trust boundary.

The response carries access_token, issued_token_type and token_type (N_A when the artefact is not an access token, such as a JWT authorization grant). refresh_token is optional; do not issue one for short-lived exchanged tokens. Errors use invalid_request for unacceptable tokens and invalid_target when the STS will not issue a token for the requested resource or audience.

Subject tokens, actor tokens and the act claim

The subject token represents the principal whose authority is being used, usually a user's access token or ID token. The actor token represents the service or agent doing the work, typically its own client assertion or workload token. When both are present, the STS can issue a token whose sub is the user and whose act claim identifies the actor.

• act claim: the RFC 8693 act claim (section 4.1) "provides a means within a JWT to express that delegation has occurred". Its members are identity claims such as sub and iss; claims like exp, nbf and aud are not meaningful inside it.
• Nested act: "The outermost act claim represents the current actor while nested act claims represent prior actors." A token that has passed through a gateway and then a worker therefore carries the whole delegated access chain.
• Authorisation rule: consumers "MUST only consider the token's top-level claims and the party identified as the current actor". Do not grant access because a trusted service appears somewhere in the nested chain.
• may_act claim: section 4.4 lets a token state in advance which party is authorised to act for the subject. The RFC example names [email protected] as permitted to act for [email protected]. The STS should compare the actor token against may_act and refuse delegation to anyone else.

An exchanged token for a reporting API, issued to a worker that was itself called by a gateway, might carry claims like these:

{
  "iss": "https://sts.example.com",
  "aud": "https://reports.example.com",
  "sub": "user-4821",
  "scope": "reports.read",
  "exp": 1792310400,
  "act": {
    "sub": "spiffe://example.com/ns/finance/sa/report-worker",
    "act": { "sub": "spiffe://example.com/ns/edge/sa/api-gateway" }
  }
}

The reporting API authorises user-4821 with reports.read, acted for by report-worker; the gateway entry is audit only.

Delegation vs impersonation

RFC 8693 draws the line precisely. Under impersonation, "A is B within the context of the rights authorized by the token". Under delegation, "principal A still has its own identity separate from B". An impersonation token exchange is a request with a subject token and no actor token, producing a token indistinguishable from one issued to the user; a delegated token exchange adds the actor token.

Impersonation should be a recorded exception with narrow scope and short lifetime, never the default for an agent or integration. The Agentic AI Identity Guide covers the agent identity models that sit on top of these mechanics.

On-behalf-of flows in practice

"On behalf of" in OAuth describes a pattern, not one protocol: on behalf of delegation means a service obtains an on behalf of token for a downstream API using the user's authority. Three implementations are common.

• RFC 8693 with an actor token: the most expressive form, producing a delegated access token with an act claim. Support varies by authorization server, so confirm the STS can emit act and enforce may_act before designing around it.
• Microsoft Entra ID on-behalf-of: the middle-tier API calls the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer, requested_token_use=on_behalf_of and the incoming user token as assertion. The assertion must have the middle tier as its aud; a token meant for Microsoft Graph "can't redeem it using OBO". The flow works only for user principals, uses delegated scopes rather than application roles, and returns interaction_required with a claims challenge when Conditional Access needs step-up, which the middle tier must relay to the client as a 401.
• Agent on-behalf-of: Microsoft Entra Agent ID blueprints cannot run interactive /authorize flows; they receive a user token audienced to the blueprint and perform an OBO exchange as the child agent identity. Microsoft says client secrets "shouldn't be used" for blueprints in production.

Whatever the protocol, the on behalf of authorization decision belongs to the authorization server: it checks that the user consented to (or an administrator pre-authorised) the downstream scopes, that the client may act for users at that resource, and that the result is narrower than the input. Watch pre-authorisation features such as Entra's preAuthorizedApplications, which let listed applications obtain delegated permissions "without the user providing consent". Review that list like a privileged role assignment.

Token downscoping and audience restriction

RFC 9700 section 2.3 says "the privileges associated with an access token SHOULD be restricted to the minimum required" and that access tokens should be audience-restricted to one resource server. Token exchange is where that happens in multi-hop systems.

• One audience per token: request a single resource or audience per exchange. Resource servers must reject tokens whose aud does not name them.
• Scope intersection: the STS issues no more than the subject token held. Requests for scopes the subject lacks should fail, not silently succeed with the STS's own authority.
• Shorter lifetime: exchanged tokens expire no later than the subject token, usually within minutes.
• Sender constraining: RFC 9700 recommends mutual TLS (RFC 8705) or DPoP (RFC 9449) so a stolen exchanged token cannot be replayed from elsewhere.
• Platform downscoping: Google Cloud Credential Access Boundaries let you derive a token with fewer permissions than its service account, up to 10 access boundary rules, currently for Cloud Storage only.
• Transaction tokens: the IETF Transaction Tokens draft (revision 11 at the time of writing) uses token exchange to replace the external access token at the edge with a short-lived JWT, carried in a Txn-Token header inside the trust domain. Replacement tokens may reduce scope but never expand it.

Cross-domain and external token exchange

The identity assertion authorization grant uses an OpenID Connect token exchange to extend single sign-on to API access: the IdP, not each user, decides whether application X may obtain a token for application Y. In every cross domain token exchange the receiving domain maps the subject to its own users and applies its own policy; the issuing domain's claims never grant rights directly. See the Cloud Workload Identity Guide.

Multi-agent and service chains

Multi agent token exchange applies the same rules to chains where an orchestrator delegates to sub-agents and tools. Each agent should hold its own workload identity, present it as the actor token, and exchange the token it received for one aimed at the next tool. The resulting nested act chain shows the full path, while each hop is authorised on the user plus current actor only.

• No passthrough: the MCP authorization specification states that an MCP server calling upstream APIs uses "a separate token, issued by the upstream authorization server" and "MUST NOT pass through the token it received". Apply the same rule to every agent framework. See the MCP Security Guide.
• Depth limits: set a maximum delegation depth in STS policy (for example three actors); long chains usually indicate a design fault or a loop.
• Monotonic scope: each exchange must be equal to or narrower than the last. An agent should never obtain a scope at hop three that the user did not hold at hop one.
• Human approval for high-impact actions: for irreversible actions require step-up or user confirmation, not delegated scope alone. See the AI Agent Authorisation Guide.

Choosing a pattern

• Service or agent acting for a user inside one IdP: RFC 8693 delegation with an actor token where the authorization server supports act; otherwise the platform OBO flow, with actor identity logged from client_id or azp.
• Many internal microservices behind one gateway: exchange the external token once at the edge for an internal token or transaction token, rather than letting every service talk to the external IdP.
• Workloads outside the cloud provider: workload identity federation, not exported service account keys.
• Application to application across companies or SaaS tenants: identity chaining or ID-JAG, where both sides support them; otherwise a per-integration OAuth client with narrow scopes.

Small organisations can rely on their IdP's built-in OBO and cloud federation and focus on audience validation and no-passthrough rules. Large estates with many APIs benefit from a dedicated STS tier with policy as code and a registry of which clients may exchange for which audiences.

Implementing token exchange safely

1. Inventory forwarding: find services that forward inbound bearer tokens or call downstream with broad client credentials; the same jti or token hash at several resource servers is a reliable signal.
2. Fix validation first: make every resource server enforce aud, iss, signature and expiry. Until it does, exchanged tokens add little.
3. Define exchange policy: for each client, list permitted subject token types, actor requirements, target audiences, maximum scopes, maximum lifetime and delegation depth. Store it as reviewable configuration.
4. Pilot one chain: pick a single gateway to service path, issue exchanged tokens in parallel while the old path still works, and compare authorisation decisions in logs.
5. Switch and enforce: move the pilot to exchanged tokens, then configure the downstream API to reject tokens not issued by the STS for its audience.
6. Roll back cleanly: keep the previous credential path disabled but available for one release; rollback is re-enabling it, not widening STS policy.
7. Extend and sender-constrain: roll out chain by chain, then add mTLS or DPoP binding and remove refresh tokens from exchanged grants.

Detection and measurement

Log every exchange at the STS with: client ID, subject sub and issuer, actor sub, subject and requested token types, requested and issued audience and scope, delegation depth, decision and reason. Downstream, log sub, the current act.sub and the token jti. MITRE ATT&CK T1528 (Steal Application Access Token) and T1550.001 (Use Alternate Authentication Material: Application Access Token) describe what you are trying to spot: tokens reused from unexpected clients or used without a matching sign-in.

• Alert on: audiences outside a client's allow-list; invalid_target bursts; impersonation exchanges from clients registered for delegation; issued scope wider than the subject token; depth above policy; one jti seen at two resource servers.
• Metrics: percentage of service-to-service calls using exchanged rather than forwarded tokens; percentage of delegated tokens carrying an act claim; median lifetime of exchanged tokens; number of clients allowed impersonation; rejected exchanges per week with reviewed causes; resource servers enforcing audience validation.

Common failure patterns

• Token passthrough: a middle tier forwards the user's token, so compromising one service yields tokens valid elsewhere.
• Unauthenticated exchange: the STS accepts any valid subject token without client authentication, so a stolen token can be converted into tokens for other audiences, the exact abuse RFC 8693 warns about.
• Authorising on nested actors: a downstream API grants access because a trusted gateway appears anywhere in the act chain, contrary to the RFC's top-level-only rule.
• Exchange that widens scope: the STS issues what the client is allowed rather than the intersection with the subject's rights, turning a low-privilege user token into a powerful one.
• Weak STS key protection: whoever holds the signing key can mint any exchanged token. In the Microsoft Storm-0558 key breach one stolen signing key was enough to forge tokens for government email.
• Long-lived delegated grants held by integrations: refresh tokens stored by a third party outlive the need. The Salesloft Drift breach shows the result when such tokens are stolen.

Framework mapping

Practitioner checklist

• Ban token passthrough in architecture standards and test for it in API gateway logs.
• Require client authentication, preferably private key JWT or mTLS, for every token exchange client.
• Maintain per-client exchange policy: allowed subject and actor token types, audiences, maximum scope, lifetime and delegation depth.
• Use actor tokens and act claims for services and agents acting for users; treat impersonation as an approved exception.
• Enforce may_act where tokens carry it, and authorise on top-level claims plus the current actor only.
• Issue exchanged tokens with one audience, no wider scope than the subject token and a lifetime of minutes, without refresh tokens.
• Protect STS signing keys in an HSM or cloud key management service and rehearse key rotation.
• Restrict external token exchange with attribute conditions and allow-listed issuers.
• Review pre-authorised and admin-consented OBO applications quarterly.
• Log every exchange decision centrally and alert on scope widening, unknown audiences and replayed jti values.

Standards and references

• IETF: RFC 8693 OAuth 2.0 Token Exchange
• IETF: RFC 8707 Resource Indicators for OAuth 2.0
• IETF: RFC 9700 OAuth 2.0 Security Best Current Practice
• IETF: RFC 7523 JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
• IETF: OAuth Identity and Authorization Chaining Across Domains (draft)
• IETF: Identity Assertion JWT Authorization Grant (draft)
• IETF: Transaction Tokens (draft)
• Microsoft Learn: OAuth 2.0 On-Behalf-Of flow

Related NHI Mgmt Group resources: OAuth 2.0 and OpenID Connect Guide · Token and Session Security Guide · Agentic AI Identity Guide · AI Agent Authorisation Guide · Cloud Workload Identity Guide