Authentication & Authorization — JWT & OAuth 2.0

One-liner: Authentication proves who you are; Authorization proves what you're allowed to do. JWT and OAuth 2.0 are the industry standards for doing both at scale. 🎫 JWT — JSON Web Token A self-contained, signed token that carries claims about the user. No database lookup needed to verify. Structure: Header.Payload.Signature eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjQyLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MDAwMDB9.abc123sig HEADER PAYLOAD SIGNATURE { { HMACSHA256( "alg": "HS256", "userId": 42, base64(header) + "." + "typ": "JWT" "role": "admin", base64(payload), } "iat": 1699999999, secretKey "exp": 1700003599 ← expires in 1hr ) } JWT Flow 1. Login: Client ──► POST /login {email, password} Server validates, creates JWT Client ◄── { token: "eyJ..." } 2. Use API: Client ──► GET /profile Headers: Authorization: Bearer eyJ... Server decodes JWT, checks exp, checks role Client ◄── { user data } Stateless = Scalable Server doesn't store sessions. Any server instance can verify the token using the secret key. No Redis/DB lookup needed per request. JWT Risks & Mitigations Risk Mitigation Token stolen Short expiry (15min) + Refresh tokens Can't invalidate before expiry Refresh token blacklist in Redis Payload visible (base64 ≠ encrypted) Never store sensitive data in payload Weak secret Use RS256 (asymmetric) for multi-service 🔑 OAuth 2.0 — Delegated Authorization OAuth lets a third party app access resources on your behalf, without sharing your password. "Sign in with Google" is OAuth 2.0 in action. Authorization Code Flow (Recommended) User Client App Authorization Server Resource Server | | (Google/GitHub/etc) (Your API) |──"Login"─────►| | |──Redirect──►| | | client_id | |◄──────────────| | |────Login to──►| | | Google | | | |◄─auth code──| | | | | |──POST /token| | | code + | | | client_secret | |◄─access_token + refresh_token | | | | |──GET /userinfo (Bearer access_token)───►| | |◄── { id, email, name }──────────────────| | | |◄──Logged in!──| Key OAuth Concepts Term What It Is Client Your app Resource Owner The user Authorization Server Google, GitHub, Auth0 (issues tokens) Resource Server API that accepts access tokens Access Token Short-lived (1hr) — use to call APIs Refresh Token Long-lived (30 days) — exchange for new access token Scope Permissions granted: read:email, write:profile 🔐 Session vs JWT Comparison Session JWT Storage Server-side (Redis/DB) Client-side (localStorage / cookie) Revocation Instant (delete session) Must wait for expiry (or blacklist) Scale Needs shared session store Stateless — any server works Payload Just session ID Full claims (userId, role, etc.) Best for Monolith, small-medium scale Microservices, APIs, mobile ✅ Pros JWT: Stateless, scalable, no DB lookup per request, cross-service OAuth: No password sharing, granular scopes, industry standard for SSO ❌ Cons JWT: Revocation is hard, payload visible, long tokens add overhead OAuth: Complex flow, misconfig is a security disaster, token leakage risks ⚖️ When to Use / When NOT to Use ✅ JWT — use when: REST APIs serving mobile or SPA clients Microservices that need to pass identity between services Stateless, horizontally scaled backends ✅ OAuth — use when: Third-party "Sign in with X" integrations Allowing external apps to access user data on your platform Enterprise SSO (Single Sign-On) ❌ Avoid JWT when: You need instant logout / token revocation (use sessions with Redis) Highly sensitive systems where payload visibility is a concern