What Is OAuth?
Source: Hacker News
Background
A recent question on X (formerly Twitter) asked for a “Matt Levine‑style” explanation of how OAuth works and, more importantly, why it was designed the way it is.
“I desperately need a Matt Levine style explanation of how OAuth works. What is the historical cascade of requirements that got us to this place?” – geoffreylitt
The asker isn’t looking for a low‑level walkthrough of the various flows; they want to understand the motivating use cases that shaped the design.
Sign‑In Use‑Case (OpenID Connect)
The simplest way to see OAuth in action is through OpenID Connect (OIDC), which builds on OAuth to provide authentication. OIDC can be thought of as a “magic‑link” login:
- The server sends a secret to a location only the user can access (e.g., their email or a mobile app).
- The user proves they can access that location by presenting the secret back to the server.
If the secret checks out, the user is authenticated. All the surrounding specifications—vocabulary, UX details, and additional security checks—are layers added over this core idea.
Why a New Standard Was Needed
In late 2006, while working on Twitter, the team wanted to support OpenID 1.0 so that Twitter wouldn’t become a centralized identity holder. However, the existing OpenID flow required a password, which didn’t work for desktop clients or emerging mobile apps.
Other sites had ad‑hoc solutions (Flickr, AWS, Delicious, etc.), but they were insecure and custom. The need was for a standard, secure way for third‑party applications to act on a user’s behalf without exposing the user’s password.
That gap led to the creation of OAuth as a delegated‑authorization protocol.
Core Idea of OAuth
At its essence, OAuth is a two‑part process:
- Consent & Secret Distribution – The user (resource owner) gives consent and an authorization server issues a multi‑use secret (an access token) to a trusted delegate (the client application).
- Token Use – The delegate presents that secret to the resource server to perform actions on behalf of the user.
Everything else—refresh tokens, scopes, PKCE, token introspection, etc.—is additional machinery that makes the basic pattern secure and interoperable.
Historical Context
- 2006‑2007: Need for password‑less sign‑in for third‑party clients.
- 2007: First OAuth draft written.
- 2009: OAuth 1.0 published (signature‑based).
- 2012: OAuth 2.0 released, simplifying the flow (bearer tokens) and adding extensibility.
- 2014‑present: OpenID Connect built on top of OAuth 2.0 to provide standardized authentication.
The evolution reflects a balance between security, usability, and extensibility. Standards bodies added “noise” (e.g., token revocation, dynamic client registration) to address real‑world threats and developer experience.
Practical Takeaway
When implementing OAuth, start by answering:
- What are you trying to achieve? (e.g., allow a mobile app to post on a user’s behalf.)
- Why is delegation needed? (e.g., you don’t want the app to know the user’s password.)
Once the goal is clear, the OAuth flow (authorization code, implicit, client credentials, etc.) becomes a set of mechanical steps that satisfy those constraints.
Conclusion
OAuth’s design is rooted in a simple problem: how can a user safely grant limited access to a third‑party application without sharing credentials? The rest of the specification is the result of decades of incremental improvements, security hardening, and consensus‑building.
Understanding that core motivation demystifies the protocol and makes it far less inscrutable.