OAuth 1.0 vs. OAuth 2.0

OAuth 1.0a required every single request to be individually signed: the consumer built a canonical signature base string from the HTTP method, the URL and every parameter, computed an HMAC-SHA1 (or RSA-SHA1, or PLAINTEXT) signature over it, and the service provider had to reconstruct the identical base string to verify it. Three concrete costs followed directly from this:

OAuth 2.0’s answer, from OAuth WRAP through RFC 6749/6750, is the bearer token: a single opaque or structured string presented as Authorization: Bearer <token>, no signing step, no canonicalisation, verified by comparing (or decoding) the token itself rather than recomputing anything from the request. The cost moves entirely onto transport security — TLS is not optional the way it was under 1.0a, because a bearer token gives an eavesdropper everything a signature never would.

RFC 5849 has no equivalent of RFC 6749’s authorization server / resource server split as distinct, named roles with different responsibilities — the "service provider" issued tokens and served resources as one undifferentiated party. OAuth 2.0 makes the split explicit (see Getting started with OAuth) and, crucially, makes centralised token issuance a first-class deployment pattern: one authorization server can issue tokens honoured by many independently operated resource servers, each validating locally (for a JWT) or by calling back to the issuer (for introspection) — exactly the shape a microservice architecture with one identity provider and many APIs needs, and exactly what 1.0a’s single undifferentiated "service provider" role does not describe.

OAuth 1.0a has one flow (three-legged, or its two-legged reduction) that every consumer uses regardless of what kind of application it is. OAuth 2.0 instead defines grant types — and the ecosystem has kept adding more since — each matched to a specific client shape: authorization code for server-side web apps (and, with PKCE, for public clients too — details), client credentials for service-to-service calls with no user (details), the device authorization grant for input-constrained hardware (details), and token exchange and assertion grants for delegation across service boundaries (details). See Flows overview for the full decision tree.

An OAuth 1.0a access token, once issued, is typically long-lived by convention, with no standardised expiry or renewal mechanism — revoking it usually meant the service provider deleting it out-of-band. OAuth 2.0 makes short-lived access tokens the norm, with expires_in in every token response, and adds the refresh token as a separate, longer-lived credential used only at the token endpoint to obtain a new access token without repeating the whole interactive flow. This bounds the blast radius of a leaked access token to its (short) lifetime, and lets rotation, reuse detection and revocation of the refresh token happen independently — the whole subject of Access and refresh tokens.

OAuth 1.0a grants access to "whatever the service provider’s authorization page said it was granting", with no standardised, machine-readable way for the consumer to request a narrower capability or for the token to carry one. OAuth 2.0’s scope parameter, present on the authorization request, the token request and the token response, makes the requested capability explicit and inspectable at every stage, and is the seed for the richer models — claims, Rich Authorization Requests, resource indicators — covered on Scopes, claims and permissions.

RFC 5849 describes a complete, fixed protocol: implementing it means implementing exactly what it says, and extending it means writing a new specification from scratch. RFC 6749 was deliberately written as a framework with explicit extension points — new grant types, new token types, new client-authentication methods — which is exactly why the entire extension decade (PKCE, device flow, token exchange, DPoP, PAR, JAR, and more) could ship as independent RFCs against the same base specification rather than requiring a new major version of the protocol every time the ecosystem needed something new.

A signed OAuth 1.0a request cannot be replayed by someone who merely intercepts it in transit, because the signature is bound to that specific request and the attacker does not have the secret needed to forge a new one. A bearer token has no such property by design: whoever holds it, can use it — a token that leaks through a logging pipeline, a referrer header, a misconfigured proxy, or a compromised browser extension is immediately and fully usable by whoever obtained it, indistinguishably from the legitimate client. RFC 6749/6750 accepted this trade-off explicitly in exchange for the simplicity described above; the gap sat unresolved in mainstream practice for the better part of a decade before mTLS-bound tokens (RFC 8705) and DPoP (RFC 9449) reintroduced proof of possession, deliberately narrowed to the deployments and token types where the cost is worth paying — see Sender-constrained tokens: DPoP and mTLS. In a real sense, this is OAuth 1.0a’s request-signing insight returning to OAuth 2.0, just no longer applied to every single request by every single client.

Eran Hammer-Lahav’s resignation complaint (covered in full) was precisely this: because RFC 6749 leaves so much to profiling — which grants a deployment supports, which client authentication methods, whether and how tokens are structured — two independently built, fully compliant OAuth 2.0 implementations are not guaranteed to interoperate without extra, out-of-band agreement. OAuth 1.0a’s narrower, more fully specified protocol did not have this problem, simply because it left less undefined. The ecosystem’s answer has been layered rather than a single fix: discovery (RFC 8414/9728) lets a client learn a given deployment’s actual profile at runtime instead of assuming one; the Security BCP (RFC 9700) narrows the security-relevant choices to one recommended answer each; FAPI (the Financial-grade API profiles) goes further still, fixing essentially every optional choice for regulated, high-assurance deployments; and the in-progress OAuth 2.1 consolidation (draft-ietf-oauth-v2-1-16) folds a large slice of that accumulated agreement back into the base specification itself, closing much (not all) of the interoperability gap Hammer-Lahav warned about, without abandoning the extensibility that made the extension decade possible in the first place.