Product1 publisher2 min readPublished
Auth0's on-behalf-of exchange keeps the end user's identity in the downstream token
Auth0's documentation gives middle-tier services and MCP servers an RFC 8693 route to call downstream APIs as the user. The token carries the delegation chain, and the exchange has its own rate ceiling.
The Product Desk · Product desk
What happened
- Auth0 documents an On-Behalf-Of token exchange, based on RFC 8693, that lets a middle-tier service swap a user-scoped access token for one scoped to a downstream API while keeping the user's identity and permissions.
- The documented use cases are MCP servers that need to call first-party APIs on a user's behalf and microservices that need to call downstream services on a user's behalf.
- Auth0 limits that delegation chain to five nested levels.
- Buying the Auth0 for AI Agents add-on lets exchanges draw on the subscription tier's full Authentication API rate limit instead of the lower limit applied to exchanges alone.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- exposure Downstream scopes come from the user's RBAC policies, so a role grant that was merely generous for the first API now sets what every service further along the chain may do in that user's name.
- cost Logins, token refreshes and exchanges draw on one shared Authentication API ceiling, so an agent rollout spends capacity that the team answering for slow sign-ins already depends on.
- constraint Post-login Action code now runs on server-to-server exchanges as well as interactive logins, so any check written for a person sitting at a browser has to behave sensibly with no browser in the request.
- decision Audit design can move from the calling service's own logs into the token itself, because the receiving API can read which service exchanged and which client began the request without trusting the caller's account of it.
A middle-tier service holds one client-credentials token, uses it for every downstream call, and the downstream API logs the application. Auth0's documentation says what that costs: "The request may have been initiated by a user, but that context will be lost. The downstream service only knows the identity of the calling application." [2]
Teams call that setup authenticated because the request started with a login. The downstream API only ever sees the client id of whatever called it. The exchange changes what the second service is allowed to decide: the documentation lists, among the properties of the new token, that it "Enables Service B to make authorization decisions based on the end user" [3]. None of this is automatic. In the documented flow the MCP server presents the user's token to Auth0 and asks for an access token scoped to the first-party API [17], and the azp claim on what comes back should match the outermost act.sub, identifying the service that performed the most recent exchange [6].
The throughput numbers matter for rollout planning. Exchanges are capped at 30 requests per second [9]. With the Auth0 for AI Agents add-on, a Private Cloud tier rated at 100 requests per second can run exchanges up to that full 100 [10], about 3.3 times the default exchange ceiling [1]. The same documentation tells you not to spend that capacity twice: cache access tokens for their lifetime, because "repeated token exchanges waste resources, increase latency, and may trigger rate limits" [12].
This is for the team putting an MCP server in front of first-party APIs, and for microservices already handing user requests to each other. Calls out to third-party APIs on a user's behalf go through Token Vault instead [14]. The page does not list a price for the add-on and tells readers to contact their Technical Account Manager [15].
The check to run before Monday is a count. Take the longest path a single user request travels, and count the services on it that need to act as the user. An exchange fails once the subject token already carries four nested act levels [8], so the stop you hit in production is one level below the documented five [2]. A path at or past that count needs either a service account at the last hop or a fresh authorization partway along.
What to watch
- Whether Auth0 publishes list pricing for the AI Agents add-on or keeps the higher exchange ceiling behind a Technical Account Manager conversation.
- Whether the five-level nesting cap rises as agent call chains get longer in practice.
- Whether Auth0 documents how the act delegation chain behaves when a call leaves for a third-party API through Token Vault.