Every API needs to answer: who is this user, and what are they allowed to do? Roll your own auth and you'll have a CVE within months. OAuth 2.0 is how you delegate authentication to a trusted identity provider. JWTs are how you carry proof of identity between services.
Understand both, including when NOT to use JWTs as sessions (a surprisingly common mistake).
OAuth 2.0 is an authorization protocol, not an authentication protocol. OpenID Connect (OIDC) sits on top of OAuth to add authentication. When people say "OAuth login," they usually mean OIDC + OAuth together.
The modern canonical flow for web apps (with PKCE extension for public clients):
client_id + requested scopes + redirect URI + PKCE challenge.Key insight: the access token never touches the browser. Client-side Single-Page Apps use PKCE to prevent code interception; public clients get the code via redirect but also need the PKCE verifier (secret only the client knows) to exchange it.
JSON Web Token — three base64 parts joined by dots: header.payload.signature.
HEADER {"alg":"RS256","typ":"JWT"}
PAYLOAD {"sub":"42","iss":"https://auth.example.com","exp":1735689600,"roles":["admin"]}
SIGNATURE RS256-signature over header + payload
Server verifies by recomputing the signature with its public key. Tampered payload → signature mismatch → reject. The payload (claims) is not encrypted — it's base64, readable by anyone. Don't put secrets in there.
Standard claims: sub (subject/user), iss (issuer), exp (expiry), aud (audience), iat (issued at). Custom claims (roles, tenant_id) are added by the issuer.
Every request carries the JWT. Server verifies signature + expiry. No DB or Redis lookup. Catch: revoking access before expiry is hard. If a user's JWT is stolen, they keep access until it expires (usually 15 min to 1 hour).
Token is an opaque ID; server looks up sessions:abc123 in Redis. Easy to revoke — just DELETE the key. Adds a Redis round-trip per request but Redis is fast. Industry default for user sessions.
Using JWTs as user sessions because "stateless is cool." Then trying to add revocation, which requires the very session store you tried to avoid. Moral: use JWTs for service-to-service auth and short-lived access tokens; use opaque tokens for long-lived user sessions.
Access tokens are short (15 min). Refresh tokens are long (days/weeks/months) and used to mint new access tokens without re-asking the user.
Threats:
Auth0, Okta, and every modern IdP do all three by default. If you're rolling your own, follow OAuth 2.1 draft recommendations — they codify what's actually safe.
Identity-as-a-service. Handles social login, MFA, enterprise SSO, user management. Most SaaS companies use one of these instead of DIY auth.
Same pattern but integrated with other AWS services. Cheaper at scale if you're AWS-heavy; less polished UX than Auth0/Okta.
Self-hosted. Full-featured. You own the DB. Used by teams with strict data residency needs.
Istio/Linkerd issue workload identities. Cert-based auth between pods. No JWTs needed inside the mesh.
E-commerce uses OAuth for login + JWTs for service-to-service. WhatsApp uses device-based auth with refresh tokens. Payment gateway uses OAuth client credentials flow for merchant API access.
