OAuth 2.0
The standard authorization framework for delegated access: a user grants a third party limited access to their resources on your service without sharing their password. It's how 'Log in with X' and API scopes work.
- Third-party access to user data ('Log in with Google').
- Machine-to-machine with client credentials.
- First-party browser sessions (use session cookies + OIDC).
- Internal service auth where mTLS suffices.
Definition
OAuth 2.0 defines flows where a resource owner authorizes a client to access resources via access tokens issued by an authorization server. Scopes limit what the token can do. Common flows: authorization code (with PKCE), client credentials, device code.
Why it exists
Sharing passwords with third parties is insecure and gives full access. OAuth scopes a token to specific actions for a specific client, revocable, without exposing credentials.
How it works
Client redirects the user to the auth server; user consents; auth server redirects back with a code; client exchanges code (+ PKCE verifier) for an access/refresh token; client calls APIs with the bearer token. Refresh tokens renew access without re-prompting.
Scaling limits
Token validation on every request needs fast verification (JWT self-validating, or introspection cache). Token revocation before expiry is the hard part with stateless JWTs.
Cost shape
Auth server infra (token issuance, consent UI, key rotation). Per-request token validation cost. Refresh token storage and rotation.
Alternatives
- API keys — Simpler, but no delegated consent, scopes, or revocation per user.
- mTLS — Strong service identity but not user delegation.
Failure modes
- Implicit flow leaking tokens in URLs (use auth code + PKCE).
- Refresh token theft (use rotation and detection).
- Open redirects in the callback.