Buried in RFC 6749, the OAuth 2.0 specification published in October 2012, there's a pronoun doing more architectural work than anyone probably intended:
"An end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username and password."
She authenticates directly with a trusted server. She clicks Authorize.
The entire authorization flow pivots on that click. A human, present, consenting, reading a permissions screen and making a decision. The spec defines a "resource owner" as "an entity capable of granting access to a protected resource" and notes that when that entity is a person, it's called an end-user. Non-human resource owners are technically possible. But the spec's architecture, its examples, its flow diagrams all assume someone is there to say yes.
Eran Hammer, the lead author who resigned from the OAuth 2.0 project in July 2012, called the result:
"More complex, less interoperable, less useful, more incomplete, and most importantly, less secure."
His critique targeted enterprise interests reshaping a web-native design. The strain he identified, though, has aged into something he likely didn't anticipate: the framework was already buckling under its own assumptions about who would be on the other end of every authorization decision.
Fourteen years later, the OAuth 2.1 draft (March 2026) consolidates a decade of security improvements. The resource owner model persists. And a new clarification appears: using OAuth tokens as proof of identity, a widespread practice, is "not part of the OAuth standard or security considerations." The standard is explicitly disowning one of its most common uses. Once agents start holding tokens as proxy identities, that disowned practice becomes load-bearing.
The Model Context Protocol's authorization specification walks directly into this tension. The current spec states plainly: "A human user completes the OAuth flow through a web browser, obtaining an access token that identifies them personally." The human is still the hinge. But MCP also needs agents to connect to servers they've never encountered before, which requires dynamic client registration. Think of it this way: without dynamic registration, every agent developer would need to manually set up credentials with every server their software might ever contact. Aaron Parecki, co-author of OAuth 2.1, identified this as "the OAuth for the Open Web problem." The human who would have done that setup work, one server at a time, isn't there.
Consent fractures first. When a user authorizes an agent to send emails, does that mean any emails, to anyone, indefinitely? The MCP community's emerging answer is that consent must account for who is delegating, to which agent, for what purposes, and it must be revocable. One OAuth grant can't carry all of that.
Identity fractures next. The spec distinguishes between impersonation and delegation: ideally, the agent should remain distinguishable from the user while acting on their behalf. Clean on a whiteboard. Still unresolved in production.
By some accounts, over half of MCP servers still rely on static API keys, sidestepping the OAuth flow entirely. The careful consent model, the delegation architecture, the human-in-the-loop assumption: all bypassed by a shared secret pasted into a config file.
OAuth and SSO built an identity model around a singular, present, consenting human. One person, one session, one deliberate click. Agents act on behalf of users who aren't present. They need permissions that shift by the minute. They operate across services that have never heard of them. The "Authorize" button was designed for someone who could read it, understand it, and decide. That someone is increasingly not in the room.