Open On-Behalf-Of Flow is an authentication delegation pattern where one application obtains a token to call another service on behalf of a signed-in user. The downstream service receives user context and delegated claims, while the upstream app never handles the user’s password directly and only gets the scoped access it needs.
What the OBO flow is for
Open On-Behalf-Of flow is used when an app must call a downstream service with the user’s delegated context, not with the user’s password. It preserves a clear trust boundary: the upstream app requests a token with just enough authority to act for the signed-in user.
This pattern matters because it separates user authentication from service-to-service access. The downstream service can make an authorization decision based on the caller, the user context, and the token claims, rather than relying on the upstream app to impersonate the user or relay credentials.
How delegation works in practice
At a high level, the signed-in user authenticates to the first application, which then exchanges that user context for a downstream token. The resulting token is constrained to the specific audience, scope, and delegated rights needed for the next service call.
The important distinction is that the upstream app is not becoming the user. It is presenting an identity assertion or delegated token that says, in effect, “this call is being made for this user, under these limits.” That is why on-behalf-of designs are closely tied to token exchange, consent, and least privilege.
In mature implementations, the security value comes from narrowing what the middle tier can do. Done well, delegation is explicit, auditable, and bounded. Done poorly, it can collapse into broad impersonation or token reuse across services.
Why OBO differs from simple authentication
OBO is not just “sign in once and reuse the same token everywhere.” It is a delegation model for multi-tier systems where one application needs to act for a user while another system must still understand who the end user is.
That distinction helps avoid overexposing credentials and keeps the downstream service responsible for its own authorization checks. It also makes it easier to separate user login from backend access, which is especially important in distributed applications, APIs, and agent-like workflows that need constrained delegated access.
For readers who want the underlying specification, RFC 8693: OAuth 2.0 Token Exchange defines the delegation and impersonation mechanics that underpin this pattern.
Common design mistakes and control boundaries
OBO breaks down when teams treat delegated access like a generic bearer-token handoff. If the token is too broad, reused across audiences, or accepted without validating the actor and subject relationship, the downstream service loses the ability to distinguish delegation from direct user access.
The other common failure is unclear ownership of the trust boundary. The upstream application should request only the delegated rights it needs, while the downstream service should enforce what that token can actually do. The pattern works only when both sides respect scope, audience, and claim validation.
A practical way to think about it is that OBO reduces password exposure, but it does not remove authorization responsibility. It shifts the security burden toward token integrity, claim validation, and careful service-to-service policy enforcement.
Risk and Threat Considerations
OBO concentrates trust into token handling, so failures usually show up as over-broad delegated access, token replay, or abuse of a service that can mint downstream tokens. If an attacker compromises the upstream app, they may be able to use that delegation path to reach data or actions the user never intended to expose.
Failure mechanism: Weak audience validation, excessive scopes, or poor token exchange controls let a compromised intermediary turn user context into unauthorized downstream access.
Impact: Attackers can move laterally through trusted APIs, access user-bound data, and persist through delegated credentials even when the original password is never disclosed.
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 NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OBO depends on managed tokens and credentials for delegated access. |
| AC-6 — Least Privilege | OBO is meant to constrain delegated access to only what the downstream call needs. | |
| IA-9 — Service Identification and Authentication | OBO commonly secures service-to-service calls where a middle tier acts for a user. | |
| Recommendation — Enforce lifecycle and protection controls for tokens used in delegated flows. Limit delegated scopes and permissions to the minimum required for the request. Authenticate services separately and validate delegated claims before authorizing downstream access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | OBO uses token-based authentication between services and can fail when token handling is weak. |
| Recommendation — Validate token issuance, audience, and lifetime to prevent abuse of delegated API access. | ||
| NIST SP 800-63 | Federation and assertion-based authentication — Federation and assertion-based authentication | OBO relies on trusted assertions and exchanged tokens rather than password forwarding. |
| Recommendation — Use assertion-based flows that preserve subject context without exposing user passwords. | ||
Practitioner Guidance
Why practitioners should care: OBO is a security boundary, not just an integration convenience. Treat the delegated token as a high-value control point and verify that every exchange step preserves the intended user, audience, and scope separation.
Common misunderstanding: Teams often assume “on behalf of” means the upstream app can safely behave like the user. In practice, the safer model is constrained delegation, where the app can act only within explicitly issued limits.
Practitioner takeaway: Design OBO so the downstream service can independently verify who is acting, for whom, and under what scope, because that is where the security value is either preserved or lost.
Related resources from NHI Mgmt Group
- How does the OAuth On-Behalf-Of (OBO) flow work between systems?
- How should organisations respond when an internal web application exposes an open redirect through a trusted return flow?
- What are the signs that a SAML authentication flow is failing open instead of validating the response properly?
- What are the signs that an authorization flow is failing open in practice?