OAuth On-Behalf-Of Flow is a delegation pattern that lets one application call another service using a user’s identity without collecting the user’s password again. In practice, the first app exchanges its token for a downstream access token, preserving user context while limiting direct credential exposure across services.
What OAuth On-Behalf-Of Flow Does
OAuth On-Behalf-Of Flow is a delegation pattern that preserves user context across service-to-service calls. It matters when one application needs to act for a signed-in user without re-prompting for credentials, because the downstream service can receive a token that represents that user rather than the first app’s own identity.
Conceptually, this separates user authentication from downstream authorization. The first application does not become the user, it becomes a constrained intermediary that requests a new access token for a specific audience and use case.
Why It Exists in Modern Systems
Distributed applications often need to call more than one backend after a single sign-in. On-behalf-of flow avoids handing passwords or broad long-lived credentials from one tier to another, while still carrying enough identity context for the next service to make an authorization decision.
This pattern is most useful when the downstream service must know who initiated the request, not just which app is speaking. It is common in API chains, enterprise integrations, and federated application designs where user context has to survive multiple hops.
Because the flow depends on token exchange rather than credential sharing, it reduces direct exposure of the user’s primary secret material. The trade-off is that every participating service must handle token audience, scope, and delegation semantics correctly, or the chain can become too permissive.
How Token Exchange Preserves User Context
The key mechanic is token substitution, not token forwarding. The upstream app presents an existing token and receives a downstream token that is suitable for the target service, ideally with a narrower scope and a clear audience restriction.
That downstream token should answer three questions: who initiated the request, what the downstream service is allowed to do, and which service is the intended recipient. When those boundaries are explicit, the application chain can keep user intent intact without exposing the original credential across every hop. RFC 8693: OAuth 2.0 Token Exchange defines the token exchange model that underpins this delegation pattern.
In practice, this is why on-behalf-of flow is often discussed alongside actor claims, subject tokens, and downscoping. The model is designed to keep delegation visible and constrained rather than implicit and open-ended. OAuth Token Exchange and Delegation Guide explains those delegation mechanics in more detail.
Where It Can Go Wrong
Delegation only remains safe if each hop enforces the intended trust boundary. If an application can exchange tokens too broadly, or if a downstream service accepts a token without checking audience and scope, the flow can turn into a privilege amplification path instead of a confinement control.
The same pattern also increases the value of bearer tokens as attack targets. If a downstream token is stolen, it may be replayed until it expires, which is why sender-constraining, narrow scoping, and careful audience design matter so much in this flow. For broader OAuth deployment guidance, RFC 9700: Best Current Practice for OAuth 2.0 Security is the current security baseline.
It is also easy to confuse on-behalf-of delegation with simple impersonation. The useful distinction is that a well-designed flow preserves accountability, so downstream logs and policy decisions can still reflect the originating user and the delegated application separately.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token exchange flows depend on controlled credential and token lifecycle handling. |
| IA-9 — Service Identification and Authentication | On-behalf-of flow is a service-to-service delegation pattern that relies on authenticated non-human callers. | |
| AC-6 — Least Privilege | Delegated tokens should carry only the minimum access needed for the downstream call. | |
| Recommendation — Manage token issuance, rotation, and revocation so delegated access cannot outlive its intended use. Authenticate services before allowing token exchange or downstream API access. Issue downstream tokens with the narrowest scopes and audiences needed for the request. | ||
| OWASP ASVS | V10 — OAuth and OIDC | This flow is an OAuth delegation pattern and depends on correct token handling and trust decisions. |
| Recommendation — Verify OAuth token exchange behavior, audience checks, and delegation handling in your implementation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | If token exchange or bearer token validation is weak, delegated calls can be forged or replayed. |
| Recommendation — Harden token validation so downstream services reject forged, replayed, or misbound tokens. | ||