OAuth

In 2006, Blaine Cook was working on Twitter’s API and facing a problem that was becoming increasingly common among web developers. He was looking for a way to connect Twitter to Flickr, the photo-sharing service. The only available solution was to ask users to entrust their Flickr credentials to Twitter. A security aberration, but it was the norm at the time.

This technical impasse prompted Cook and other developers from major web platforms to come together. Google had AuthSub, Yahoo used BBAuth, AOL offered OpenAuth, and Flickr had its own API. Everyone was cobbling together their own solution independently. They needed to move beyond this fragmentation. In October 2007, their collaboration resulted in OAuth 1.0, an open protocol designed to solve this puzzle: how to authorize a third-party application to access a user’s data without ever handling their password?

The mechanism relies on a simple yet effective principle. Imagine an online printing service that wants to access photos stored on another site. Instead of demanding the photo account credentials, it obtains a specific access token, limited to only the necessary operations. The user maintains control: they explicitly authorize access from a secure interface on the site hosting their photos. The printing service never knows the password.

The first security flaws emerged, and in June 2009, OAuth 1.0a corrected vulnerabilities that allowed identity spoofing. This revision clarified gray areas in the initial protocol and strengthened protections against attacks. The following year, in April 2010, the IETF published OAuth 1.0 as RFC 5849, conferring official technical specification status upon it.

The protocol defines three actors: the resource owner (the user), the client (the application requesting access), and the authorization server. The application first obtains temporary credentials. It then redirects the user to an authorization page where they review the requested permissions. After validation, the application receives a token it will use for future requests. At no point does it handle the user’s credentials.

Security relies on safeguards. Each request must be signed with a secret key. The protocol incorporates unique tokens (nonces) and timestamps to block any malicious reuse attempts. The designers anticipated session hijacking, replay attacks, and spoofing.

Facebook, Google, Microsoft, and Twitter adopted OAuth. This massive adoption by web giants created an ecosystem of interconnected applications. Libraries appeared in all common programming languages, making integration more accessible.

But OAuth 1.0 showed its limitations. The implementation complexity, particularly for cryptographic request signing, discouraged developers. Native mobile applications, increasingly numerous, posed problems not originally anticipated. These constraints motivated a complete overhaul of the protocol with OAuth 2.0.

The OAuth protocol established the standard for delegated authorization on the web. It introduced concepts now central: explicit user consent, strict limitation of granted privileges, clear separation between authentication and authorization.

OAuth also played an educational role. Developers and users became aware of the issues surrounding personal data protection. The protocol demonstrated that it was possible to create interconnected services without sacrificing security. This awareness accompanied the evolution of privacy regulations.

Moreover, modern architectures bear the mark of OAuth. OpenID Connect builds on its foundations to add a standardized authentication layer. REST APIs and microservices adopt its architectural principles. Connected devices and decentralized identity systems explore new paths starting from the foundations laid by OAuth.

The community continues to adapt the protocol to new uses. Feedback from large-scale deployments feeds reflections on its future evolution. OAuth remains a pillar of web security, nearly twenty years after its creation.