What are OAuth and JWT?
OAuth is the protocol behind "log in with Google" — it lets a user grant your app limited access without sharing their password. JWT is a compact, signed token format often used to carry identity and claims between services. They solve related but distinct problems.
Why it matters
Delegated login and token-based auth are everywhere in modern backends and microservices. Used correctly they are secure and convenient; used carelessly they create serious holes — unverified tokens, tokens that never expire, secrets in the payload. You need to understand the flows well enough to use them safely.
What to learn
- The OAuth authorization code flow, step by step
- Access tokens vs refresh tokens
- JWT structure: header, payload, signature
- Signing and verifying, and why verification is mandatory
- Token expiry, rotation, and revocation
- Where to store tokens on the client
- The trade-offs of stateless JWT vs server sessions
Common pitfall
Trusting a JWT without verifying its signature, or treating the payload as secret. Anyone can read a JWT's payload — it is only base64, not encrypted — and a forged token is accepted if you skip signature verification. Always verify the signature and expiry, and never put secrets in the claims.
Resources
Primary (free):
- OAuth 2.0 — Official site · docs
- jwt.io — Introduction to JWT · docs
- OWASP — JWT cheat sheet · docs
Practice
Issue a signed JWT on login with a short expiry, then write middleware that verifies the signature and expiry on each protected request and rejects tampered or expired tokens. Decode a token at jwt.io and confirm you can read its payload. Done when a token with an altered payload is rejected.
Outcomes
- Walk through the OAuth authorization code flow.
- Explain JWT structure and why the payload is not secret.
- Verify a token's signature and expiry before trusting it.
- Choose between stateless tokens and server sessions with reasons.