On-behalf-of oauth

Expanded Definition

On-behalf-of OAuth, often abbreviated OBO, is a server-side delegation pattern used when one application or service needs to call another API using a user-aligned token without ever handling the user’s password. In agentic systems, it is the safer way to preserve the boundary between the human, the agent, and the downstream resource. The calling service exchanges an upstream token for a downstream token that carries the original user context, usually with constrained scope and audience, as described in the broader identity guidance around OAuth and federation in NIST Cybersecurity Framework 2.0.

Usage in the industry is still evolving because vendors sometimes describe any token exchange or delegation flow as OBO, even when the implementation is closer to simple bearer-token forwarding. That distinction matters: true OBO keeps credentials out of the agent runtime and supports least privilege, while token reuse can expand blast radius if the intermediate service is compromised. The most common misapplication is treating the model or tool agent as the delegate holder, which occurs when developers pass user tokens into prompts, tool calls, or client-side code.

Examples and Use Cases

Implementing OBO rigorously often introduces extra identity plumbing and token exchange latency, requiring organisations to weigh tighter credential containment against added integration complexity.

• A customer-support agent drafts a response, then the backend exchanges the user session for a scoped token to read billing data without exposing the original credential.
• An internal workflow service requests calendar access on behalf of a manager, but only after policy checks and consent enforcement in the server layer.
• A SaaS integration uses OBO so an automated agent can update records in Salesforce while preserving the user’s identity context for audit and authorization.
• After incidents like the Salesloft OAuth token breach, teams often revisit whether downstream access was properly delegated or simply forwarded.
• When reviewing third-party app connections, practitioners compare OBO design against federation expectations in NIST Cybersecurity Framework 2.0 to keep auth flows auditable.

In practice, OBO is also useful for step-up authorization, delegated admin tasks, and MCP-backed tool execution where the agent must act with user context but not user custody of secrets.

Why It Matters in NHI Security

OBO is an NHI control as much as an IAM pattern because it limits where tokens live, who can replay them, and how far a compromise can spread. When a model, tool runtime, or automation layer becomes the holder of user secrets, the organisation has effectively converted an identity delegation issue into a secrets management problem. That is especially dangerous in environments already struggling with OAuth visibility: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to Astrix Security & CSA.

The risk is not theoretical. Poorly designed delegation contributes to long-lived access, weak revocation, and over-broad downstream scopes, which are recurring themes in incidents such as the Dropbox Sign breach. For NHI governance, OBO should be paired with NIST Cybersecurity Framework 2.0 identity and access controls, plus Zero Trust Architecture principles, so delegation remains ephemeral, scoped, and observable.

Organisations typically encounter the consequences only after a token leak, account takeover, or unauthorized API call, at which point on-behalf-of OAuth becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for NHIs?
• Why can't OAuth 2.0 and OIDC alone fully solve NHI authentication challenges?
• What is the difference between OAuth 2.0 and SPIFFE and when should each be used?