What is the OAuth on-behalf-of flow for AI agents?
By Identra · Updated
The OAuth on-behalf-of flow lets a service exchange an incoming user access token for a token to call a downstream API in that user's context. An AI agent can use this pattern for delegated access, but the flow does not prove that each action matches the user's intent.
Key numbers
- 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024 (Gartner press release, June 2025)
- Over 40% of agentic AI projects will be canceled by the end of 2027, in part due to inadequate risk controls (Gartner press release, June 2025)
How does the OAuth on-behalf-of flow work?
A client sends a user access token to a middle-tier API. When that API needs another service, it authenticates to the authorization server and presents the incoming token to request downstream access. The downstream API receives the newly issued token and enforces its own authorization rules.
In Microsoft's OBO implementation, the incoming access token must be intended for the middle-tier API. The flow uses delegated permissions and requires appropriate consent before the exchange can succeed. It does not turn an application-only token into user delegation. See the Microsoft OBO documentation.
Treat the exchange as an authorization boundary. Document which service may request which downstream permissions and for whose benefit. For AI agent delegation, also define the task the agent may perform. A valid token alone does not express that task.
How is OBO different from token exchange and client credentials?
On-behalf-of describes a delegated access scenario and is also the name of Microsoft's specific implementation. OAuth token exchange is a broader protocol that can support delegation or impersonation. These terms do not identify interchangeable requests or guarantee identical token contents. OAuth Token Exchange specification
Choose the model based on whose authority the operation needs. A user-requested document lookup and an unattended inventory job may need different authorization designs. Avoid giving an assistant application-wide access merely because user delegation takes more integration work.
Microsoft OBO
- Authority used
- Delegated user context
- Typical purpose
- A middle-tier API calls another API for a user
OAuth token exchange
- Authority used
- Determined by exchange policy and token semantics
- Typical purpose
- Exchange tokens across services or trust boundaries
Client credentials
- Authority used
- The application's own authority
- Typical purpose
- A service runs without delegated user context
Does an OBO token identify the agent acting for the user?
Do not assume every OBO token contains an agent identity. Token exchange defines an optional act claim that can identify the current actor separately from the subject. Whether that representation appears depends on the implementation and authorization server policy.
Nested act claims can represent previous actors. Under the token exchange specification, those previous actors are informational, not inputs to access-control decisions. An actor claim also does not establish an automatic revocation mechanism. Actor claim specification
For an operational AI audit trail, record the initiating user, authenticated application, agent or workflow identifier, requested operation, target resource, and outcome. Correlate service requests without logging raw tokens. Verify which identifiers the provider actually supplies before promising per-agent attribution.
What does secure OBO look like in an enterprise AI assistant?
Consider an internal assistant asked to summarize a customer contract. The employee signs in, and the assistant's backend receives a token for its API. That backend obtains delegated access to the document service. The document service checks both the delegated permission and the employee's access to the requested contract.
A sound design keeps document retrieval separate from actions such as changing sharing permissions or sending email. The summarization task should not automatically gain those capabilities. If the employee cannot read the contract, the assistant should report the access failure instead of retrying with a broadly privileged service identity.
This example shows why least privilege must cover both scopes and application behavior. A read permission may still cover many documents. Restrict the task to approved resources, and require a separate decision before using retrieved content in an external action.
What security risks remain after token exchange?
An agent can misuse legitimately delegated authority. A malicious instruction embedded in a document could redirect it toward unrelated files or an unauthorized recipient. OBO does not prevent prompt injection, and successful API authorization does not establish that the employee requested the action.
An intermediary can also become a confused deputy if it lets an untrusted caller select sensitive targets without checking that caller's authority. Tenant boundaries, resource ownership, and task restrictions still need explicit enforcement.
Bearer tokens remain valuable to attackers. Audience restrictions limit where a stolen token can be accepted, but do not prevent replay at its intended API. Protect tokens from logs, browser storage, prompts, and tool output. OAuth security guidance recommends audience restriction and sender-constrained tokens where applicable. OAuth security best practice
How should security teams secure and test OBO?
Make delegation reviewable from consent through resource access. Include the integration in OAuth app risk reviews, with a named owner and a documented reason for each downstream permission.
Test denied operations as carefully as successful ones. A working demo proves token acquisition. It does not prove isolation between users, tenants, agents, or tasks.
- Validate token issuer, audience, lifetime, and integrity using supported libraries. Enforce the required permissions at each API.
- Allow only approved downstream resources and scopes. Keep token exchange parameters under trusted application control.
- Separate token caches by user, tenant, client, and relevant authorization context. Test that concurrent users cannot receive each other's tokens or data.
- Keep credentials and tokens in protected storage. Use supported credential rotation and avoid exposing tokens to model context.
- Require explicit approval for sensitive actions such as external sharing or destructive changes. Bind approval to the actual target and operation.
- Test wrong-audience tokens, missing consent, inaccessible resources, and revoked grants. Document when existing access tokens stop working rather than assuming revocation is immediate.
- Preserve request correlation and authorization outcomes so responders can identify affected users, applications, and resources.
How Identra thinks about it
Identra gives security teams visibility into OAuth grants, including the application, permissions, and grantor, so delegated access can be reviewed. Analysts can revoke risky grants and retain the response result, helping teams address unnecessary access held by connected applications.
Go deeper: AI security, built on identity
Frequently asked questions
Can an ID token be used for OBO?
Microsoft's OBO flow expects an access token intended for the middle-tier API. An ID token describes authentication to a client and is not a substitute for that API access token.
Does OBO require the user to approve every API call?
No. Required consent must be established, but the backend exchange does not present an approval screen for every operation. Task-specific approval must be implemented separately when needed.
Can an agent keep working after the user closes the browser?
Closing a browser does not necessarily invalidate issued tokens. Continued access depends on token lifetimes, renewal capabilities, provider policy, and the application's design.
Does OBO automatically reduce permissions?
No. The requested permissions and authorization server policy determine what is issued. Request narrow access and verify the resulting permissions instead of assuming every exchange reduces authority.
Does revoking consent immediately stop every downstream call?
Do not assume it does. Existing access tokens may remain usable depending on the provider and resource server. Test the actual revocation behavior and include that delay in incident response planning.