Before OAuth, the way you let a third-party application access your account was simple and terrible: you gave it your password. Twitter apps, email clients, photo-printing services. They stored your credentials, often in plain text, and logged in as you. If any one of them got breached, the attacker had your actual password.
This was the specific problem a small group of developers set out to solve in late 2006. Blaine Cook was working on Twitter's OpenID implementation. Chris Messina and Larry Halff were thinking about similar questions elsewhere. By December 2007, the OAuth Core 1.0 spec was final. The protocol's name said what it did: open authorization. Authorization only. Authentication and identity were someone else's concern, and the separation was deliberate. OpenID Connect wouldn't arrive to handle identity until years later, precisely because OAuth's designers considered it out of scope.
The design centered on consent. A human decided what to share and with whom. RFC 6749, the OAuth 2.0 specification published in October 2012, made this assumption grammatical:
"When the resource owner is a person, it is referred to as an end-user."
The resource owner was, by default, human. Section 4.4 included a provision for cases where no human was present, the client credentials grant, but it read like an accommodation for edge cases where access had been "previously arranged with the authorization server."
The transition from 1.0 to 2.0 was contentious enough to crack the project open. Eran Hammer, who had served as lead author and editor, resigned publicly in July 2012, withdrawing his name from the specification. His critique was pointed: the protocol had become a framework, reshaped by enterprise interests into something that no longer guaranteed interoperability. One compromise was renaming it from a protocol to a framework. Another was adding a disclaimer warning that the specification was unlikely to produce interoperable implementations.
Nobody in the working group seems to have anticipated which part of the loosened framework would bear the most weight. The client credentials grant, that edge-case provision, became the dominant pattern for API infrastructure. No human in the loop. A service holds a client ID and secret, exchanges them for a short-lived token, presents the token on API calls. And here the clean separation between identity and authorization quietly fell apart. When a machine authenticates with client credentials, the credentials represent the machine itself. There is no absent human whose permissions are being borrowed. The permission became the identity. The distinction OAuth was built to preserve stopped holding in the context where the protocol now saw most of its use.
No RFC author declared the protocol suitable for this. The migration was emergent. The exception case absorbed the majority of traffic, and the consent model that justified the protocol's existence receded into a vestigial feature of the spec.
The language is still there. "When the resource owner is a person." The spec still assumes, in its grammar if not its usage, that someone is home. OAuth validates individual requests, and the entities now making those requests generate sequences, reason about problems, decide which tools to invoke. Each call might be authorized. The combined action across a chain of invocations can produce an outcome that no single token check ever evaluated. The protocol checks permissions at the door. What happens inside the building was always someone else's problem. The occupant used to be a person who understood what building they were in. Nothing in the protocol asks whether that's still true.