The OAuth 2.0 On-Behalf-Of flow lets a middle-tier API exchange an incoming user token for a new token to call another downstream API as that user. It preserves the user context across services without passing the original token around. Defenders should restrict consent, validate token audience and scopes, and ensure each API only accepts tokens intended for it.
How the OBO flow differs from ordinary delegated OAuth
microsoft entra id’s On-Behalf-Of flow is a delegation pattern, not a general token relay. The middle tier receives a user token for one API, validates it, and then exchanges it for a second access token that is scoped for the downstream API. That keeps the user context intact while preventing the original token from becoming a reusable pass-through credential.
The practical distinction is audience and trust boundary. The incoming token proves the user authenticated to the first API, but the downstream API should not trust that token directly unless it was minted for that resource. OBO is how you preserve delegation without collapsing the boundary between front-end, middle-tier, and downstream service.
For a broader treatment of the delegation model and the token exchange mechanics behind it, see OAuth Token Exchange and Delegation Guide.
What the middle tier actually exchanges and why that matters
In an OBO chain, the middle-tier API uses the incoming user token as proof of delegated authority when it requests a new token from Entra ID for the downstream API. The downstream token is a fresh artifact with its own audience and scope, so the second API can enforce its own authorization rules instead of inheriting the first API’s permissions by accident.
This is why OBO is often described as “act for the user” rather than “share the user’s token.” The middle tier does not become the user, and it should not need to expose the original bearer token to logs, caches, or other services. The design reduces token sprawl and makes audience separation enforceable at each hop.
The underlying standard is RFC 8693, which defines token exchange for delegation and impersonation. Microsoft Entra ID’s OBO implementation follows that model conceptually, so the safest way to reason about it is as a token exchange flow with strict resource targeting, not as a custom shortcut around OAuth. If you need the base protocol shape, RFC 8693: OAuth 2.0 Token Exchange is the authoritative reference.
Where OBO breaks down in real Entra ID deployments
OBO works cleanly only when each API validates that the token it receives was minted for it and that the scopes match the action being requested. If the middle tier accepts a token for the wrong audience, or if the downstream API is permissive about scopes, delegation turns into unintended token reuse. That is the common failure mode practitioners should look for first.
Another weakness is consent and application registration sprawl. OBO depends on the middle tier being allowed to request downstream tokens on the user’s behalf, which means app permissions, delegated permissions, and consent policy all matter. If those controls are loose, the flow can be abused for overbroad access or consent phishing even when the protocol itself is used correctly.
For attackers, the attractive part is not the exchange step alone but the trust the exchange creates. A compromised middle tier can become a pivot point to downstream resources, and a malicious or overprivileged app can turn delegated access into persistent data exposure. Restricting who can request downstream scopes and who can register or consent to apps is therefore part of the OBO control surface, not just general Entra hardening.
Microsoft Entra application and consent controls are the practical place to tighten that surface, especially when user-delegated access crosses multiple APIs. The Entra ID Applications and Consent Guide is a useful companion when you need to decide how much delegated access your tenant should actually permit.
Risk and Threat Considerations
OBO concentrates trust in the middle-tier API, so compromise there can amplify into downstream access even if the original user token never leaves the service boundary. The main exposure is not just token theft, but audience confusion, overbroad delegated scopes, and app consent paths that let a malicious or compromised service act as a durable broker.
Failure mechanism: A middle tier accepts or forwards tokens without enforcing audience, scope, and consent boundaries, allowing a compromised app or misconfigured service to exchange legitimate user context for broader downstream access than intended.
Impact: Attackers can pivot from one API to another under a valid user context, exfiltrate data through trusted service paths, or retain access through app permissions even after a user session ends.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OBO relies on controlled handling of token-like authenticators and their lifecycle. |
| AC-3 — Access Enforcement | Downstream APIs must enforce resource-specific authorization for exchanged tokens. | |
| AC-6 — Least Privilege | OBO should limit delegated access to the minimum scopes needed by the downstream call. | |
| Recommendation — Manage token handling and rotation so delegated credentials are not reused beyond their intended scope. Enforce resource-specific access checks on every API that receives a delegated token. Grant only the minimum delegated scopes required for each API hop. | ||
Practitioner Guidance
What to verify: Confirm that the middle tier validates the incoming token’s issuer, audience, and delegated scopes before it requests a downstream token, and that the downstream API rejects any token not minted specifically for it.
Decision rule: If a service can exchange user tokens for a downstream API, treat that service as a privileged trust boundary and review its consent, app registration, and scope grants before you expand functionality.
Common mistake: Treating OBO as a transparent plumbing detail. In practice, it is an authorization design choice, and the security outcome depends on whether each hop preserves least privilege and resource separation.
Practitioner takeaway: OBO is safe when it narrows delegation to the exact downstream resource and scope needed; it becomes risky the moment the middle tier is allowed to act as a general-purpose token broker.
Related resources from NHI Mgmt Group
- How does the OAuth 2.0 authorisation code flow work with Microsoft Entra ID?
- What breaks when OAuth consent approval is abused in Microsoft Entra ID?
- Why do role changes and OAuth consent grants in Microsoft Entra ID create higher risk than ordinary administrative activity?
- Which OAuth flows do AI agents use in Microsoft Entra Agent ID?