How does the OAuth On-Behalf-Of (OBO) flow work between systems?

How OBO works as delegated authorization

OAuth On-Behalf-Of, or OBO, is a token exchange pattern, not a second login. One system receives a user token, proves it can act for that user, and swaps the incoming token for a new downstream token that is targeted to the next API or service. The downstream token should carry only the delegated permissions needed for that hop.

That distinction matters because the calling system is not supposed to forward the original bearer token unchanged. A proper OBO design narrows the audience, preserves the user context where required, and separates the upstream trust boundary from the downstream one. The result is a controlled delegation chain rather than a shared token being reused everywhere.

OBO is easiest to think about as a translation step between systems. The upstream token says, in effect, “this user already proved themselves here,” while the downstream token says, “this caller may act for that user in this specific resource context.” That keeps consent, scope and audience aligned with the service that is actually being called.

For the underlying standard mechanics, the most relevant references are RFC 8693: OAuth 2.0 Token Exchange and RFC 6749: The OAuth 2.0 Authorization Framework.

What has to remain true at each hop

Each hop in an OBO chain should re-check three things: who the original subject is, which authority the caller has been delegated, and which resource the token is meant for. If any of those drift, the downstream service may accept a token that was never intended for it, or may treat broad upstream permission as if it were a fresh grant for the new service.

Issuer validation and audience validation are the practical guardrails here. The downstream service should only trust tokens from the expected issuer and only for the intended audience. Scopes or equivalent claims should be checked again at the point of use, because delegated permission that is acceptable for one API may be excessive for another.

It is also important to distinguish delegation from impersonation. OBO is meant to preserve the user context while constraining what the middle system can do. If the middle tier can mint or pass through tokens without those constraints, the pattern stops being delegation and starts becoming a token relay problem.

The cleanest way to implement this is to anchor OBO to the token exchange model and to avoid designing ad hoc forwarding paths. When the architecture already has a dedicated exchange step, the semantics are clearer and the token boundaries are easier to audit.

For practical design guidance, OAuth Token Exchange and Delegation Guide is the most direct internal reference, and RFC 8707: Resource Indicators for OAuth 2.0 is useful when you need audience-restricted tokens for a specific resource.

Where OBO usually goes wrong in real systems

Most OBO failures are boundary failures. The first is token forwarding, where a service simply passes the user token along instead of exchanging it. That can expose broader permissions than the downstream service needs, and it can make later auditing unable to tell which hop actually consumed the credential.

A second failure is over-trusting the middle tier. If the intermediary is allowed to request downstream tokens without strong checks on the original token, it can become a privilege amplifier. A third is weak logging, which hides the delegation path and makes it hard to answer basic questions after an incident, such as which service called which API for which user and under what scope.

There is also a replay risk when OBO relies on bearer-style handling without sender constraints. If a token is stolen in transit or from logs, an attacker may be able to reuse it until it expires. That is why sender-constrained patterns and strict token handling matter even when the primary goal is delegation rather than secrecy.

For secure token handling and audience restriction, RFC 9700: Best Current Practice for OAuth 2.0 Security and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) are the most relevant external references.

Practitioner Guidance

What to verify: Confirm that every downstream API validates issuer, audience and delegated scope independently, rather than trusting whatever the calling tier sends along. If the service cannot explain why it accepted the token, the delegation chain is too loose.

Implementation sequence: First, define the exact downstream resources that need OBO, then decide which claims must survive the exchange, and only then choose the exchange mechanism. This sequence prevents teams from building a generic token relay and calling it delegation.

Common mistake: Treating a user token as portable across tiers is the fastest way to lose control of privilege boundaries. The safer rule is that a token should be re-minted for the next hop, not reused by default.

What practitioners underestimate: OBO is as much about observability as it is about authorization. If you cannot trace delegation paths end to end, you will struggle to distinguish legitimate delegated access from abuse, and incident response will be slower than the exposure warrants.

Practitioner takeaway: Good OBO design makes delegation narrow, explicit and auditable; if the middle tier can forward or reshape tokens without strict audience and scope checks, the pattern has failed operationally even if it still “works.”

Related resources from NHI Mgmt Group

• What are the implications of using OAuth tokens in third-party integrations?
• Why is OAuth token management critical in cloud environments?
• What makes OAuth tokens risky in NHI environments?
• Why is OAuth considered a better alternative for MCP servers?