What is the OAuth on-behalf-of flow for AI agents?
By Identra · Updated
The OAuth on-behalf-of flow is a delegation pattern in which a service or AI agent exchanges a token issued for a user into a new token that lets it call downstream APIs as that user. The issued token carries the user's identity and, when the authorization server supports it, an act claim naming the agent, so the delegation chain can stay visible.
Key numbers
- 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024 (Gartner press release, June 2025)
- Over 40% of agentic AI projects will be canceled by the end of 2027, in part due to inadequate risk controls (Gartner press release, June 2025)
Why AI agents strain classic OAuth delegation
OAuth was designed for a person consenting to one application. An AI agent breaks that shape: it plans its own steps, chains calls across many APIs, and often runs long after the user who launched it has closed the tab. When the agent simply reuses tokens minted for its user, every log line shows the user acting, and nothing distinguishes delegated agent activity from the user themselves or from an attacker replaying a stolen token.
That ambiguity compounds as agents multiply. Each copilot, workflow bot, and autonomous assistant becomes another non-human identity holding user-derived credentials, and agent sprawl means the population grows faster than any review process. The on-behalf-of pattern exists to keep the user's identity attached to the request chain while making the intermediary, human-built service or AI agent, explicit and accountable.
How the classic on-behalf-of flow works
The best-known implementation is the middle-tier API pattern: a client calls API A with the user's access token, and API A needs to call downstream API B as that user. Instead of forwarding the original token, API A presents it back to the identity provider together with its own client credentials and asks for a new token scoped to API B. Microsoft's OBO flow is a vendor-specific implementation that uses the jwt-bearer grant type with a requested_token_use parameter set to on_behalf_of; standards-based deployments implement the same idea through RFC 8693 token exchange, and the two should not be conflated.
Three properties define the pattern. The exchange happens on the back channel, authenticated by the middle tier's own credential. The new token is re-audienced, so a token accepted by API A can never be replayed directly against API B. And the flow carries delegated scopes: permissions stay attached to the user rather than to the application acting for them, and where the authorization server supports scope narrowing, the exchange can stay inside least privilege boundaries. The flow also works only for user principals; a service acting purely as itself uses client credentials instead.
Token exchange and the act claim
RFC 8693, OAuth 2.0 Token Exchange, published in January 2020, generalizes the pattern. A caller presents a subject_token representing the user and, optionally, an actor_token representing itself. Whether the issued token is a composite token whose act claim names the acting party is left to authorization server policy; the RFC does not guarantee it. Where act claims are issued they can nest, so a chain of services, or a chain of agents calling agents, can produce a readable delegation history inside the token itself.
For AI agents the act claim is the difference between an audit trail and a guess. A resource server that sees sub for the user and act.sub for the agent can enforce agent-specific policy, rate limits, and revocation without losing the user context. What RFC 8693 does not natively provide is a front-channel step where the user explicitly consents to a specific agent, since it was designed for server-to-server exchange after consent has already happened.
The emerging extension for AI agents
An IETF individual draft, draft-oauth-ai-agents-on-behalf-of-user, proposed closing that consent gap; the draft expired in February 2026 without adoption, but it shows the shape such a deployment profile would take. Rather than inventing a new grant, it extends the authorization code flow with two parameters: requested_actor, which identifies the specific agent on the consent screen, and actor_token, which the client presents at the code exchange to prove the agent's identity. The resulting access token binds three parties, the user in sub, the client in azp, and the agent in act.sub.
Major identity providers are shipping agent-aware variants of the same idea, issuing agents their own first-class identities and letting them obtain delegated tokens rather than borrowing the user's session. The direction of travel is consistent across vendors: the agent authenticates as itself, the user consents to that agent by name, and every downstream token records both. The same primitives are surfacing in MCP authorization, where servers acting for users need scoped, exchangeable tokens rather than pasted API keys.
Risks and governance
Delegation concentrates authority in the intermediary, and an intermediary that accepts untrusted input is a confused deputy waiting to be exploited. An agent holding on-behalf-of tokens can be redirected by prompt injection to spend the user's authority on an attacker's goals, and every action it takes will look like legitimate delegated activity. The failure modes to engineer against:
- Over-scoped exchanges: agents granted broad delegated scopes accumulate standing privilege; request the narrowest scope per task and prefer just-in-time issuance
- Token theft: exchanged tokens and the refresh tokens behind them are bearer credentials, and stealing one inherits the whole delegation, the same post-authentication blind spot as session hijacking
- Consent sprawl: each agent integration is an OAuth grant that outlives the experiment that created it, the classic OAuth app risk pattern applied to agents
- Invisible chains: without act claims, multi-hop agent calls collapse into the user's identity and no log can reconstruct who actually acted
- Ungoverned agents: on-behalf-of tokens issued to shadow AI tools bypass the review that sanctioned integrations receive
How Identra thinks about it
The on-behalf-of flow is necessary plumbing, not governance. An act claim only helps if something is reading it: correlating the agent named in the token with the agent actually running, checking that its behavior matches the user's intent, and revoking the delegation the moment it drifts. That is a runtime identity problem. Organizations that treat delegated agent tokens as set-and-forget grants will rediscover every OAuth consent failure of the SaaS era at agent speed; the ones that watch delegation chains at the moment of use turn the on-behalf-of flow into what it was meant to be, a precise and revocable statement of who is acting for whom.
Go deeper: The Non-Human Majority
Frequently asked questions
How is the on-behalf-of flow different from token exchange?
They solve the same problem at different levels of generality. The on-behalf-of flow is the scenario, a middle tier or agent calling downstream APIs as the user, and Microsoft's OBO grant is one implementation of it. RFC 8693 token exchange is the standardized mechanism: subject_token in and, where authorization server policy allows, a composite token with an act claim out, usable for delegation and impersonation alike.
Why not just pass the user's original token to the agent?
Because the original token was audienced for one API and says nothing about the agent. Forwarding it lets any downstream service replay it, hides the agent from every audit log, and makes agent activity indistinguishable from the user or from an attacker with a stolen token. Exchanging it can produce a re-audienced, narrower token that names the agent in an act claim, when the authorization server supports those features.
What does the act claim record?
The identity of the party acting on the user's behalf. The token's sub claim stays the user, while act.sub names the agent or service that performed the exchange. Act claims can nest, so a chain of delegations, user to agent to sub-agent, can remain readable in the final token and drive agent-specific policy and revocation. Whether an act claim is issued at all depends on authorization server policy.
Does the on-behalf-of flow stop prompt injection?
No. It scopes and attributes the damage rather than preventing it. An injected agent still holds a valid delegated token and can misuse it within its granted scopes. The flow's contribution is that the misuse is attributable to a named agent and revocable per agent, which is why it needs to be paired with narrow scopes, short lifetimes, and runtime monitoring.