---
title: "On-Behalf-Of Is a Pattern. Token Exchange Is the Standard."
description: "The post distinguishes the On-Behalf-Of pattern from the OAuth 2.0 Token Exchange standard (RFC 8693) and Microsoft’s implementation, warning against forwarding a user’s token downstream as it breaks the audience trust boundary. Token Exchange uses a subject_token for the user’s identity and an optional actor_token to record the calling service, with a chainable act claim for multi-hop calls. Microsoft’s implementation uses a jwt-bearer grant, only works for user principals, and can mint SAML assertions for legacy integrations, but the resulting token must never be relayed back to the client. For AI agents, neither OBO nor Token Exchange handles explicit user delegation, so integrators must log act claims, scope tokens to specific tasks, issue per-agent credentials, and build audit trails. The post notes the confused deputy problem resurfaces with agents, and regulatory transparency requirements around automated decision-making are already in effect."
---

# On-Behalf-Of Is a Pattern. Token Exchange Is the Standard.

[Auth0](https://yomu.fyi/company/auth0) · Andrea Chiarelli · Oct 16, 2026

**Type:** Explainer

## Summary

The post distinguishes the On-Behalf-Of pattern from the OAuth 2.0 Token Exchange standard (RFC 8693) and Microsoft’s implementation, warning against forwarding a user’s token downstream as it breaks the audience trust boundary. Token Exchange uses a subject\_token for the user’s identity and an optional actor\_token to record the calling service, with a chainable act claim for multi-hop calls. Microsoft’s implementation uses a jwt-bearer grant, only works for user principals, and can mint SAML assertions for legacy integrations, but the resulting token must never be relayed back to the client. For AI agents, neither OBO nor Token Exchange handles explicit user delegation, so integrators must log act claims, scope tokens to specific tasks, issue per-agent credentials, and build audit trails. The post notes the confused deputy problem resurfaces with agents, and regulatory transparency requirements around automated decision-making are already in effect.

## Context

The post clarifies the distinction between the On-Behalf-Of architectural pattern, the OAuth 2.0 Token Exchange standard (RFC 8693), and Microsoft’s vendor-specific implementation. It explains the delegation problem where a middle-tier service needs to act on behalf of a user without forwarding the user’s original token. The post then discusses how AI agents introduce new complexity because neither OBO nor Token Exchange was designed to handle explicit user delegation to an agent, and provides practical guidance for building audit trails and scoping tokens.

## Takeaways

- Forwarding a user’s original access token to a downstream service breaks the trust boundary because the token’s audience is the middle-tier API, not the downstream one.
- OAuth 2.0 Token Exchange (RFC 8693) formalizes the On-Behalf-Of pattern using a subject\_token for the user’s identity and an optional actor\_token to record the calling service, with a chainable act claim for multi-hop calls.
- For AI agents, neither OBO nor Token Exchange handles explicit user delegation, so integrators must log act claims, scope tokens to specific tasks, issue one credential per agent per purpose, and build audit trails now rather than waiting for standards to settle.

## FAQ

### What is the difference between the On-Behalf-Of pattern and Token Exchange?

The On-Behalf-Of pattern is an architectural concept for delegation, while OAuth 2.0 Token Exchange (RFC 8693) is the IETF-ratified standard that implements that pattern in an interoperable way. Microsoft's implementation is a third, non-standard variant that predates the standard.

### Why should you not forward a user's original token to a downstream API?

Forwarding the original token is unsafe because the token's audience is the middle-tier API, not the downstream one. This breaks the trust boundary the token was scoped to, and the downstream API cannot verify the user's authorization.

### How should AI agents handle delegation on behalf of a user?

Neither OBO nor Token Exchange was designed for explicit user delegation to agents. Integrators should log the act claim, scope tokens to specific tasks, issue one credential per agent per purpose, and build audit trails now to meet regulatory transparency requirements.

**Tags:** [AI Agents](https://yomu.fyi/topic/ai-agents), [OAuth 2.0](https://yomu.fyi/topic/oauth-2-0), [Token Exchange](https://yomu.fyi/topic/token-exchange)

- Source: [Auth0](https://auth0.com/blog/on-behalf-of-is-a-pattern-token-exchange-is-the-standard)
- Source URL: https://auth0.com/blog/on-behalf-of-is-a-pattern-token-exchange-is-the-standard
- Ingested by Yomu: 2026-10-16T15:00:14.205Z

[Read original post](https://auth0.com/blog/on-behalf-of-is-a-pattern-token-exchange-is-the-standard)