AAuth Explainer
AAuth is an authentication and authorization protocol for autonomous agents and dynamic ecosystems. It is not intended as a replacement for OAuth or OIDC — it is not OAuth 3.0. It is a separate protocol for new use cases where the assumptions behind OAuth — pre-registered clients, browser redirects, bearer tokens, static scopes — are not a good fit.
What’s Changed Since OAuth
OAuth 2.0 was designed for a specific problem: a user authorizing a registered web application to access their data at a specific API provider. The user’s browser redirects to the provider, the user consents, and the application receives a bearer token. OpenID Connect extended this to federated login. Together, they serve these use cases well and continue to be the right choice for them.
But the landscape has changed:
-
Autonomous agents operate without browsers. In environments like MCP, agents interact with servers they were never pre-registered with. Many are headless processes that cannot receive browser redirects.
-
On-demand authorization across trust domains. Long-running agents discover authorization needs at runtime. Resources may be governed by different auth servers, requiring cross-domain federation that OAuth’s single-authorization-server model does not support.
-
Progressive trust is needed. Resources need different levels of assurance for different operations, but OAuth provides only a binary authenticated/unauthenticated model.
-
Consent needs context. OAuth scopes convey what access is requested but not why or under what conditions. Users cannot ask questions about what an agent intends to do.
-
Security has evolved. Bearer token exfiltration is a common attack vector. Proof-of-possession with digital signatures is now practical, yet bearer tokens remain the default.
How AAuth Addresses These Gaps
| Gap | AAuth Solution |
|---|---|
| No browser | Polling-based token delivery (202 Accepted + Location) |
| No pre-registration | Agent identity via HTTPS URLs with self-published metadata |
| Binary auth | Progressive trust: pseudonym → identity → interaction → approval |
| Opaque scopes | Justification parameter + clarification chat during consent |
| Bearer tokens | HTTP Message Signatures on every request, proof-of-possession only |
| Single auth server | Cross-domain AS federation |
| Separate authN/authZ | Unified auth token carries identity and authorization |
Learn More
- Why AAuth — Five reasons to adopt AAuth
- How It Works — Core concepts and flow
- AAuth vs OAuth/OIDC — Detailed comparison tables
- Design Rationale — Why the protocol makes the choices it does