OAuth

OAuth 1.0 began as a community specification in 2007 and was published as RFC 5849 in 2010; every request was signed with the client's and token's secrets. OAuth 2.0 (RFC 6749, October 2012) dropped request signing in favour of bearer tokens protected by TLS (RFC 6750) and became a framework rather than a single protocol. RFC 6749 §1.1 defines four roles: resource owner, client, authorization server (AS) and resource server (RS). It defines four grants: authorization code (§4.1), implicit (§4.2), resource owner password credentials (§4.3) and client credentials (§4.4), plus refresh tokens (§6). Later RFCs added the device authorization grant for input-constrained devices (RFC 8628), token exchange (RFC 8693) and guidance for native apps (RFC 8252).

The authorization code flow with PKCE is now the default for almost every client. The client generates a random code_verifier and redirects the browser to the AS's authorize endpoint with response_type=code, client_id, an exactly registered redirect_uri, the requested scope, a state value against CSRF and a code_challenge, the SHA-256 hash of the verifier (RFC 7636, method S256). After the user authenticates and consents, the AS redirects back with a short-lived, single-use code. The client redeems it at the token endpoint with the code_verifier and, if confidential, its client authentication, and receives an access token, usually with a refresh token. Because the verifier never travelled through the browser, an intercepted code cannot be redeemed.

RFC 9700, the OAuth 2.0 Security Best Current Practice (January 2025), codifies the lessons: PKCE for all clients, exact string matching of redirect URIs, no implicit grant and no password grant, refresh-token rotation or sender-constraining for public clients, and defences against mix-up attacks such as the iss response parameter (RFC 9207). Sender-constrained tokens bind the token to a key the client holds, via mutual TLS (RFC 8705) or DPoP (RFC 9449), so a stolen token alone is not enough. Access tokens may be opaque and checked through introspection (RFC 7662), or self-contained JWTs (RFC 9068); revocation is standardised in RFC 7009. The OAuth 2.1 effort folds these practices into one consolidated document.

OAuth is delegated authorization, not authentication. An access token is addressed to the resource server, so a client that treats "I received a token" as proof of who the user is can be fooled by a token issued to a different application; OpenID Connect's audience-bound ID token closes that gap. Other recurring problems are overly broad scopes, long-lived refresh tokens stored insecurely, leaked codes through open redirectors or Referer headers, and illicit consent grants, where users are tricked into authorising an attacker-registered app with mail or file scopes, which is why many tenants restrict user consent to verified publishers or low-risk permissions.