From OAuth to AgentAuth
OAuth answered: can this app access my data. AgentAuth answers: can this agent act on my behalf. Same lineage, different shape. Here is the migration guide.
What changes between the two
| Concept | OAuth | AgentAuth (Manav) |
|---|---|---|
| Subject | App / client | Agent (which is itself acting on a human's behalf) |
| Token | Access token | Delegation token |
| Scope language | Static, registered | Dynamic, per-call narrowing allowed |
| Magnitude limits | Not standard | First-class (spend caps, rate limits) |
| Revocation latency | Hours (cached tokens) | Sub-200ms target |
| Multi-step delegation | Awkward (refresh tokens) | Native chains |
| Audit fields | Subject + scope | Human DID + chain + role + magnitude remaining |
The four migration patterns
Pattern 1 — drop-in replacement. If your app already uses OAuth, the simplest migration replaces the token issuance step with a Manav delegation. Everything downstream — token verification, scope checks — looks similar. The token format extends JWT.
Pattern 2 — shadow mode. Run OAuth and AgentAuth side-by-side. New agent flows use AgentAuth; legacy app flows continue with OAuth. The two coexist for as long as you need. The audit log records both.
Pattern 3 — wrap your IDP. Add a Manav layer in front of your existing OAuth provider. The IDP continues to authenticate humans; Manav issues delegations on top. This is the cleanest option for enterprises that don't want to migrate their core IDP.
Pattern 4 — full replacement. For new products built from scratch. AgentAuth as the only auth layer. Deepest integration, fewest moving parts.
What you keep
OAuth's good ideas — short-lived tokens, refresh flow, scope-based authorization, well-defined errors — all transfer. The Manav delegation token is structurally a JWT with extensions. Your existing JWT library still works.
What you add
Three things OAuth doesn't have:
- The
manav_chainfield — a verifiable chain back to the human, including how their identity was established. - Magnitude caps — first-class spend and rate limits enforced at the relying party.
- The kill-switch hook — every token references its revocation endpoint.
The migration timeline
Realistic for a 50-engineer team running OAuth in production today:
- Week 1–2 — pick a low-risk surface (internal admin tools or a beta feature).
- Week 3–4 — wire Manav SDK behind a feature flag.
- Week 5–8 — shadow mode in staging; verify audit log parity.
- Week 9–12 — production roll-out behind feature flag, gradual ramp.
- Quarter 2 — extend to all agent flows; legacy human flows continue on OAuth.
Common objections
Engineers push back on three things. Latency — the cache makes verification 18 µs hot-path, fine for any production system. Vendor lock-in — the protocol is open, the spec is published, the reference implementation is forkable. Adding another auth dance — the integration is twelve lines and middleware, not a new platform to manage.
Frequently asked questions
What is the runtime cost? Single-digit milliseconds per tool call when the verification cache is warm. Cold verification is 1–2 ms. Both numbers are small relative to the LLM round-trip the agent is already paying.
Does it work with our existing agent framework? Yes. The protocol is host-agnostic. SDKs ship for Python, Go, Node, Rust, and TypeScript; integrations exist for LangChain, CrewAI, AutoGen, and the Claude Agent SDK. Anything that calls a tool can present a delegation.
What happens to delegations when an engineer leaves? They die at the human's offboarding. The IdP de-provisions the human; the device key is rotated; every active delegation that human signed is invalidated within 200 ms. No service-account graveyard for the new owner to clean up six months later.
Where to start
Hands-on next: delegation tokens explained ships in twelve lines; mcp identity 12 lines adds the operational layer once you have the basics. Both link to working repos; clone, integrate, run the bench.
Why the OAuth team would have built AgentAuth, given another year
Reading the OAuth working-group archives, the constraints that produced the standard are visible in every design choice. The team was building for a world of human-driven, session-bounded, browser-mediated requests. The pattern they shipped was correct for that world and is incorrect for the agent-driven, action-bounded, machine-mediated world we now inhabit. If the same team had been given another year and the requirement to design for agents, they would have shipped something close to AgentAuth — scope-tokens that encode magnitude as well as resource, delegation chains that name the human upstream, witness binding for high-stakes actions. We know this because the same engineers, in subsequent working-group conversations, have proposed exactly these primitives as OAuth extensions. AgentAuth is therefore not a rejection of OAuth. It is the OAuth the working group would have shipped if the deployment surface had matched the design surface. The continuity matters because adoption is fastest when the new standard is the next version, not the next protocol.
OAuth taught a generation of developers how to think about delegation. AgentAuth is the same lesson, applied to non-human actors.