OAuth 2.0 vs OAuth 1.0

OAuth 1.0, finalized in 2010, and OAuth 2.0, finalized in 2012, solve the same core problem — letting a third-party app act on a user's behalf without handing over a password — but they take almost opposite approaches to security and usability. OAuth 1.0 baked cryptographic request signing into the protocol itself, while OAuth 2.0 dropped signing in favor of relying on TLS for transport security and layering flexibility on top through separate grant types. That trade-off made OAuth 2.0 dramatically easier to implement and extend, which is why virtually every modern API — Google, GitHub, Slack, Stripe — uses OAuth 2.0 today, but it also pushed more security responsibility onto implementers, which is precisely what later hardening work like PKCE and RFC 9700 exists to address.

OAuth 1.0 required every API request to be individually signed using HMAC-SHA1 (or RSA-SHA1) over a canonicalized string built from the HTTP method, URL, and parameters, combined with the consumer secret and token secret. This meant a request could be verified as authentic and untampered even if intercepted, because the attacker would need the secret to forge a valid signature — but it also made client libraries notoriously fiddly to write correctly, since a single misordered parameter broke the signature. OAuth 2.0 replaced signing with plain bearer tokens sent in an Authorization header and relies entirely on TLS to protect them in transit; this is simpler to implement but means anyone who obtains the token, by any means, can use it exactly as the legitimate client would.

OAuth 1.0 offered essentially one flow: a three-legged process of obtaining a request token, redirecting the user to authorize it, and exchanging it for an access token, with no standardized way to express different trust levels or client types. OAuth 2.0 introduced a family of grant types — authorization code, client credentials, device code, and (now discouraged) implicit and password grants — designed for different scenarios: web apps, machine-to-machine services, smart TVs, and legacy migrations respectively. This extensibility is also why OAuth 2.0 needed extensions like PKCE (RFC 7636) and Device Authorization Grant (RFC 8628) bolted on afterward: the base spec deliberately left room for the ecosystem to add flows OAuth 1.0's single rigid handshake never anticipated, such as authorizing a smart TV or CLI tool that has no browser at all.