On-Behalf-Of (OBO) Token Flow is an OAuth pattern where one application exchanges a user’s access token for another token to call a downstream API. The downstream token carries the user’s delegated identity and consent, while the first application never uses the original token directly, reducing unnecessary token exposure.
How OBO token flow works
On-behalf-of token flow is a delegation pattern, not a token shortcut. The original access token represents the user’s delegated intent, and the application exchanges it for a downstream token that is scoped for the target API instead of reusing the upstream credential directly.
This separation matters because the upstream app never needs to expose or forward the user’s original bearer token to the downstream service. That reduces token sprawl, narrows where a credential can be intercepted, and lets the receiving API see a token issued for its own audience and purpose.
Where OBO sits in OAuth and delegated access
OBO is best understood as a specialised use of OAuth token exchange, where one party trades a presented token for a new token that preserves the user context while changing the audience or scope. The pattern is common in API chains, middle-tier services, and systems that need to act for a signed-in user without collapsing identities into a shared service credential.
The key design idea is delegated authority. The middle tier does not become the user, and it should not gain more access than the user and policy allow. For a formal reference point, RFC 8693: OAuth 2.0 Token Exchange defines the standard token-exchange model that underpins these flows.
Where identity propagation across services matters, the downstream token typically carries enough claims for the target API to understand who the user is, what the calling application is allowed to do, and whether the request was exchanged rather than directly presented. That makes OBO a control for trust boundaries as much as an implementation detail.
Why OBO reduces exposure and improves control
OBO reduces the blast radius of a stolen or over-shared token because the original token is not the credential that every service sees. Each hop can receive a token with its own audience, lifetime, and permissions, which helps prevent accidental token reuse across unrelated APIs.
It also supports cleaner authorization decisions. The downstream API can evaluate a token that was minted for its own use, rather than accepting a generic bearer token that might be valid in too many places. That is especially important when the application chain crosses trust domains or when one front-end service mediates access to several backend services.
OAuth Token Exchange and Delegation Guide is useful when you need the full delegation model, including actor and subject tokens, while OAuth Identity and Authorization Chaining Across Domains Guide helps when the exchange spans separate trust boundaries.
What practitioners should validate in OBO implementations
Practitioners should verify that the exchange is explicit, auditable, and constrained. The downstream token should be audience-restricted, short-lived where possible, and bound to the intended API path so that a stolen exchanged token has limited reuse value.
They should also confirm that the application is not silently falling back to token passthrough, broad scopes, or shared service credentials when the OBO path fails. A well-designed flow keeps the delegation story intact from front-end request to backend authorization decision.
NHI Authentication Guide is a practical reference for token exchange, client credentials, and service-to-service authentication patterns, while Token and Session Security Guide is useful for token lifetime, validation, and replay resistance in delegated flows.
Risk and Threat Considerations
OBO flows are attractive to attackers because they concentrate delegated access into a small number of tokens that can unlock downstream APIs. If the original user token, exchanged token, or exchange endpoint is mishandled, an attacker can pivot from a single compromise into broader access across chained services.
Failure mechanism: Weak audience restriction, overly broad scopes, token replay, or token passthrough can collapse the separation between the user-facing application and the backend API, allowing a stolen credential to work in places it was never meant to reach.
Impact: Successful abuse can expose downstream data, create unauthorized API actions, and extend the lifetime of a compromise even after the initial token is revoked, especially when exchanges are not tightly logged or bound to the intended audience.
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 |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | OBO depends on correct token exchange and delegation boundaries for API access. |
| Recommendation — Enforce audience-bound token exchange and reject reused bearer tokens at backend APIs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OBO token flow relies on secure lifecycle handling of tokens and revocation paths. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | OBO carries delegated user identity into downstream API authentication decisions. | |
| AC-6 — Least Privilege | OBO should narrow downstream access to only the delegated permissions required. | |
| Recommendation — Manage token issuance, lifetime, rotation, and revocation with strict lifecycle controls. Authenticate delegated API calls with tokens that preserve the user context and intended audience. Scope exchanged tokens to the minimum permissions needed for each backend API. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OBO is an OAuth delegation pattern governed by token exchange and audience handling. |
| V9 — Self-contained Tokens | Exchanged tokens are self-contained credentials that must be constrained for safe API use. | |
| Recommendation — Validate OAuth token exchange, claim handling, and audience restrictions in delegated flows. Issue self-contained tokens with limited scope, audience, and lifetime for backend calls. | ||
Practitioner Guidance
Why practitioners should care: OBO is only safe when the exchange preserves delegation without widening authority. Treat the flow as an authorization boundary, not just an authentication convenience, and review whether every exchanged token is genuinely narrower than the one it replaced.
What to watch for: Monitor for long-lived downstream tokens, token reuse across multiple APIs, and implementation shortcuts that forward user bearer tokens directly to backend services. Those are usually the first signs that the OBO design is losing its security value.