OAuth On-Behalf-Of (OBO) is an OAuth flow where one application obtains an access token to call another API on behalf of a signed-in user or service. The first application exchanges an incoming token for a downstream token with a narrower audience and scope, preserving delegated identity across services.
How OAuth On-Behalf-Of Works
OAuth On-Behalf-Of (OBO) is the delegated-token pattern that lets one application swap an incoming user or service token for a downstream access token that is valid for a different API and audience. It preserves the caller’s identity context without handing the original token to every service.
That exchange step is what distinguishes OBO from simple token forwarding. The downstream token is issued for the resource that actually needs it, which lets the system maintain separation between the front-end app, the API it calls, and the original sign-in context.
Why OBO Matters for Delegated Access
OBO is important whenever a request must travel across multiple services but still act under a signed-in user’s authority. It is especially useful in distributed systems, agent-mediated workflows, and service chains where each hop should see only the permissions it needs.
The security value is that delegation stays explicit. Instead of reusing a broad token everywhere, the application exchanges it for a token with a narrower audience and scope, which reduces accidental overreach and makes trust boundaries easier to define. RFC 8693: OAuth 2.0 Token Exchange is the core standard for this pattern, and RFC 6749: The OAuth 2.0 Authorization Framework provides the base OAuth model that OBO extends.
OBO, Token Exchange, and Audience Narrowing
OBO is usually implemented as a specific use of oauth token exchange. The first token identifies the original subject, then the exchange produces a new token that the downstream API can validate against its own audience and scope requirements.
This matters because a token meant for one resource should not automatically be accepted by another. Audience restriction and downscoping help prevent token confusion, and they reduce the blast radius if one service is compromised. The same pattern is often described as delegated access, actor-token exchange, or on-behalf-of authorization, depending on the platform.
Where systems use proof-of-possession, certificate binding, or resource indicators, those controls strengthen OBO by making the downstream token harder to replay and harder to misuse outside its intended target. RFC 8707: Resource Indicators for OAuth 2.0 is especially relevant when audience selection must be precise.
Common Design and Operational Considerations
OBO only works well when each service knows whether it is receiving an original user token or an exchanged downstream token. That distinction affects validation rules, consent expectations, claims propagation, and how much authority should survive each hop.
Designers also need to be careful about credential handling. If the front-end token is forwarded unchanged, or if the exchanged token is granted broader scope than required, OBO stops delivering its main benefit. For implementation guidance, OAuth Token Exchange and Delegation Guide is a useful NHIMG reference, and RFC 9700: Best Current Practice for OAuth 2.0 Security helps frame modern token-protection expectations.
Risk and Threat Considerations
OBO reduces unnecessary token exposure, but it also creates a sensitive exchange point. If an attacker can steal the incoming token, tamper with the exchange, or trick a service into accepting the wrong audience, they can pivot from one trust boundary to another and gain downstream access that should have been limited.
Failure mechanism: Weak audience checks, excessive scope, or careless token forwarding can let a compromised upstream token be replayed or exchanged for more access than intended, especially when services fail to distinguish delegation from impersonation.
Impact: The result can be lateral movement across APIs, unauthorized data access, persistent delegated access, and harder post-incident attribution because the compromise is hidden inside an apparently legitimate token flow.
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 sets 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 handling and validation across APIs. |
| Recommendation — Validate exchanged tokens carefully and reject any authentication path that allows token replay or confusion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OBO relies on secure lifecycle handling of the tokens and assertions used in exchange. |
| AC-3 — Access Enforcement | OBO narrows what downstream APIs allow a caller to do with an exchanged token. | |
| Recommendation — Manage OAuth tokens and assertions so they are issued, stored, rotated and revoked safely. Enforce audience- and scope-based authorization at each API boundary. | ||
Practitioner Guidance
Why practitioners should care: Treat OBO as a trust-boundary design choice, not just an implementation detail. The main question is whether each hop truly needs a new token with a reduced audience and scope, or whether the flow is silently broadening access.
What to watch for: Review any OBO implementation where the downstream API accepts tokens with overlapping audiences, where claims are copied without being re-evaluated, or where service-to-service calls are hard to distinguish from delegated user calls. Those are the situations where delegated access becomes over-delegated access.
Practitioner takeaway: OBO is strongest when every exchange is explicit, narrowly scoped, and validated against the target API’s own trust rules.