OAuth 2.0
OAuth 2.0 is an authorization framework that lets an application obtain limited, scoped access to a user resources without the password.
Definition
OAuth 2.0 is a delegation framework in which a resource owner grants a client application access to a protected resource by way of an authorization server. The client receives an access token that encodes or references a scope-limited grant, and presents it to the resource server. OAuth defines authorization flows — authorization code, client credentials, device code — not user authentication; the closely related OpenID Connect layer adds identity on top.
Context and scope
The standard behind "Sign in with..." buttons, mobile and SPA login, service-to-service access, and any API that must be accessed on behalf of a user or another service.
Common misconceptions
- OAuth is authentication — OAuth authorises access; use OpenID Connect or an identity layer to learn who the user is
- The access token can go to the browser — tokens are bearer credentials; unless confined to a backend, they leak and must be short-lived and bound
- Any redirect URI is fine if the client id matches — redirect URIs must be exact-match registered, or the code can be stolen
Anti-patterns
- Storing long-lived refresh tokens in browser storage where script can read them
- Issuing tokens with broader scopes than the client needs, widening the blast radius of a leak
- Skipping PKCE for public clients, allowing authorization-code interception
Related concepts
Authoritative source
What it is
OAuth 2.0 separates four roles: the resource owner, the client application, the authorization server, and the resource server. The client sends the user to the authorization server, which authenticates the user and asks them to consent to a set of scopes. If granted, the client receives an authorization code, exchanges it for an access token, and uses that token to call the resource server. The token represents consent to specific scopes for a limited time, and can be scoped, revoked, and audited independently of the password.
Why it matters
Sharing passwords with third parties is unsafe and ungovernable. OAuth replaces it with delegated, revocable, least-privilege access: a user can grant an app read access to one resource and revoke it later without changing credentials. For machine-to-machine access, the client credentials grant issues tokens to a workload identity. This makes OAuth the connective tissue of modern API ecosystems and mobile applications.
How to use it well
Match the flow to the client: authorization code with PKCE for browsers, mobile, and SPAs; client credentials for service identities; device code for input-constrained devices. Register exact redirect URIs, keep tokens short-lived, and store refresh tokens only where they cannot be exfiltrated — ideally a backend. Request the narrowest scopes that work, validate tokens at the resource server against issuer, audience, and scope, and add OpenID Connect when you need the user identity.