OAuth 2.0

OAuth 2.0 is the standard answer to a problem every app used to solve badly: letting one service access your data on another service, without handing over your password. Before OAuth, "connecting" a photo-printing app to your Flickr account often meant literally typing your Flickr password into the photo-printing app, which then had to store it, and could do anything your account could do, forever. OAuth replaces that with a token: a narrow, revocable, expiring credential the app can present instead of your password, scoped to only what it actually needs ("read your photos," not "be you").

The core exchange has a name, the authorization code grant, and a recognizable shape: the app redirects you to the service you're granting access to; you log in there (never at the app) and approve a specific scope of access; the service redirects you back with a short-lived authorization code; the app exchanges that code, server-to-server, for an access token it then uses on your behalf. OAuth 2.0 itself is only about authorization, granting access to data or actions. It says nothing about identity: that's the gap OpenID Connect (see that entry) was built to fill on top of it.

Where it comes from, including the part that's usually left out

OAuth 2.0 is RFC 6749, published by the IETF OAuth Working Group in October 2012, edited by Dick Hardt. Its predecessor, OAuth 1.0, was created a few years earlier by Eran Hammer, Blaine Cook, and a small group of engineers solving this exact problem for Twitter and other early social platforms. Hammer went on to lead the OAuth 2.0 rewrite inside the IETF for several years, and then, weeks before RFC 6749 was finalized, resigned as lead author and asked to have his name removed from the document. His public explanation ("OAuth 2.0 and the Road to Hell") argued that years of enterprise-driven committee process had produced something more complex than OAuth 1.0, while quietly dropping OAuth 1.0's mandatory cryptographic request-signing in favor of Bearer Tokens secured mainly by TLS. That trade-off is still the shape of OAuth 2.0 today, and it's the reason extensions like DPoP (see that entry), which add sender-constraining back in, over a decade later, exist at all. Solidus designed none of the original framework; it implements RFC 6749 as published.

Solidus today

auth.solidus.network is a working OAuth 2.0 authorization server: the authorization code grant with PKCE required, the refresh token grant, a DPoP-sender-constrained variant of both for Solid-OIDC clients, dynamic client registration (RFC 7591), token introspection, and token revocation. It runs on Solidus's public testnet, backed by did:solidus identities: there is no mainnet yet, and this has not been through an external audit.

See also

OIDC is the identity layer built on top. PKCE is the extension that closed OAuth 2.0's original authorization-code interception gap on public clients. Bearer Token and Refresh Token are the two credential types the token endpoint issues. Token Introspection is how a resource server checks whether one is still valid.