AAuth Explained — OAuth for AI Agents | Identity Expert

This video describes security mechanisms as defined in published standards and active Internet-Drafts. It is educational content, not a substitute for a professional security review of your own implementation. Classic OAuth assumes a user is sitting at the consent screen and the application holding the token is the final caller. AI agents break both assumptions. A coding agent, browser agent, or orchestration layer may act asynchronously, call multiple tools, and hand work to sub-agents. If you give that agent a normal bearer token, you usually give it broad scope, weak provenance, and replayable power that far exceeds the one task you actually approved. AAuth, short for Agent Authorization, is the emerging discipline of fixing that problem with existing OAuth building blocks. In this guide, we show how a user grants a narrow task envelope, how the authorization server uses RFC 8693 token exchange to mint an attenuated token for the agent, how RFC 9449 DPoP binds that token to the agent's key, and how nested `act` claims let a resource server verify the full delegation chain instead of trusting a blind bearer string. You'll see the six-step flow from user consent to sub-delegation, the wire-level token exchange request, the `cnf`, `act`, and `may_act` claims that matter in practice, and the threat model every agent platform has to face: prompt-injection confused deputy attacks, token theft, sub-agent privilege escalation, and forged delegation chains. The big idea is simple: agent authority must be narrower than user authority, provable at every hop, and useless if stolen. That means audience binding, five-minute lifetimes, monotonic attenuation, and sender-constrained tokens by default. 0:00 In this guide 0:23 Why god-mode bearer tokens break with agents 1:13 Analogy -- contractor code, not house keys 1:50 Four authorization failures in classic OAuth 2:28 How AAuth works -- consent, exchange, attenuation 3:43 On the wire -- `act`, `cnf`, `may_act`, DPoP 4:36 Threat model -- prompt injection, theft, escalation 5:37 Future outlook -- ID-JAG, OAuth 2.1, MCP auth 6:31 Sources Sources RFC 8693 -- OAuth 2.0 Token Exchange: https://datatracker.ietf.org/doc/html/rfc8693 RFC 9449 -- OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP): https://datatracker.ietf.org/doc/html/rfc9449 RFC 8707 -- Resource Indicators for OAuth 2.0: https://datatracker.ietf.org/doc/html/rfc8707 OAuth 2.1 draft: https://datatracker.ietf.org/doc/html/draf... ID-JAG draft: https://datatracker.ietf.org/doc/draft-iet... MCP Authorization Specification: https://modelcontextprotocol.io/specificat... --- Sources cited above are IETF RFCs, IETF Internet-Drafts, or the MCP open specification -- all freely reproducible for educational use. For educational purposes only. Specs evolve -- always check the latest published draft or RFC. #aauth #aiagents #oauth2 #appsecurity #identityexpert