What is OAuth On-Behalf-Of (OBO)?

OAuth On-Behalf-Of (OBO) is a token exchange pattern defined in RFC 8693 that lets an AI agent act on behalf of a user while maintaining both identities. The resulting token contains a 'sub' claim (whose permissions) and an 'act' claim (who's deciding), enabling full audit accountability for agent actions.

What is the act claim in OBO tokens?

The 'act' (actor) claim identifies who is actually performing the action, while 'sub' (subject) identifies whose authority is being used. For AI agents, 'sub' would be the user (e.g., alice@company.com) and 'act' would be the agent (e.g., expense-agent-001). This dual identity enables APIs to enforce user limits while logging agent actions.

Why use OBO tokens for AI agents instead of standard OAuth?

Standard OAuth tokens identify the user but not who made the decision. When an agent approves an expense, the audit log shows 'alice@company.com' but you can't tell if Alice clicked approve or an AI agent decided autonomously. OBO tokens add the 'act' claim to identify the agent as the actor, giving you full accountability: who granted permission (sub) and who made the decision (act).

When should I use OBO vs client credentials?

Use OBO when an agent acts on behalf of a specific user and needs that user's permissions. Use client credentials when the agent acts as itself with its own identity and permissions. For example, an expense-approval agent should use OBO (user's spending authority), while a nightly backup agent should use client credentials (system-level access).

How does OBO work with AI agents?

The user authenticates and grants consent to the agent. The agent exchanges the user's token for an OBO token at the authorization server, receiving a new token with 'sub' (user) and 'act' (agent) claims. The agent uses this token to call APIs, which can enforce user-level permissions while logging that an agent performed the action.

Can OBO tokens be chained for multi-agent scenarios?

Yes, OBO supports delegation chains where Agent A delegates to Agent B. The 'act' claim can be nested to show the full chain: Agent B's token would have 'sub' as the user and 'act' containing Agent B with a nested 'act' for Agent A. However, most authorization servers don't support chains beyond 2-3 hops due to complexity and security concerns.

Understanding OAuth On-Behalf-Of: The OBO Token Exchange Flow Explained

The Problem

AI Agents Break OAuth's Assumptions

Traditional App

👤→App→🌐

App forwards user intent

AI Agent

👤→🤖→???

Agent creates its own intent

When an agent approves an expense, the audit log shows “alice@company.com” — but Alice didn’t decide. Who’s accountable?

The Solution

Dual Identity with RFC 8693

👤

sub = authority (whose permissions)

🤖

act = actor (who's deciding)

The On-Behalf-Of token identifies both. APIs can enforce Alice’s limits while logging the agent’s actions. Full accountability.

Try It

Token Exchange Flow

Sequence Diagram

Alice's Token

—

OBO Token

—

The Difference

Audit Log Comparison

Same expense approval. What does the audit log show?

❌

Without OBO

Standard OAuth

Audit Entry

ActionExpense Approved

Amount$487.50

Useralice@company.com

Who decided????

Was it Alice clicking approve?
Or an AI agent acting autonomously?

🤷

✓

With OBO

RFC 8693 Token Exchange

Audit Entry

ActionExpense Approved

Amount$487.50

Authority (sub)👤alice@company.com

Actor (act)🤖expense-agent-001

Alice granted permission.
Agent-001 made the decision.

✅

Stakeholder Benefits

Who Benefits?

🛡️

CISO

"Agent compromised. What did it access?"

Query actor: agent-001 → instant forensic trail across all users.

📋

Compliance

"Who approved this $10K expense?"

Alice (authority) + agent-001 (actor). Both logged. Full accountability.

⚙️

Platform

"Which agents are misbehaving?"

Per-agent metrics. Spot anomalies. Rate limit or revoke specific agents.

🤖

AI Team

"Is agent v2 making better decisions?"

Compare rejection rates per agent version. A/B test with real audit data.

Limitations

Where OBO Falls Short

OBO works within a single trust domain. It breaks down when:

Multi-Hop Delegation

Agent A calls Agent B calls Agent C. The act claim only captures one layer. Who's really acting?

Cross-Organization

Agent from Org A needs to call API in Org B. Different auth servers, no shared trust anchor.

User Consent Opacity

RFC 8693 is backend-only. The user consents to the initial token, but every exchange after that is invisible. No front-channel interaction, no visibility into what scopes the agent requests or which downstream services receive tokens.

Emerging fix: IETF draft-oauth-ai-agents-on-behalf-of-user adds front-channel consent for AI agent delegation.

For emerging solutions to these challenges, see my blog post.

Learn More

BLOG AI Agents Beyond PoCs: IAM Emerging Patterns

Deep dive on OBO, agent identity, and the accountability problem

EXPLAINER MCP (Model Context Protocol)

How agents connect to tools and data

EXPLAINER A2A (Agent-to-Agent Protocol)

How agents talk to each other

RFC 8693: OAuth 2.0 Token Exchange

The official IETF specification