All skills
JWT Tokens
Stateless authentication tokens for modern web APIs
⬢ TIER 2Tech
Medium
Salary impact
3 months
Time to learn
Easy
Difficulty
1
Careers
AT A GLANCE
JWT (JSON Web Tokens) are compact, self-contained tokens used for stateless authentication in APIs and SPAs. Career path: Practitioner (basic token handling, $105-135k) → Intermediate (refresh rotation, multi-service signing, $140-160k) → Expert (JWE encryption, federated identity, revocation strategies, $165-210k) over 2-4 months. JWT structure: header.payload.signature (base64-encoded), tokens carry claims (user ID, roles, expiration) signed with HS256 (symmetric) or RS256 (asymmetric). No server-side sessions needed — scale horizontally without shared state.
What is JWT Tokens
- DPoP adding token binding security - Shorter token lifetimes with improved refresh flows
🔧 TOOLS & ECOSYSTEM
jsonwebtokenjosePassport.jsAuth0ClerkSupabase AuthFirebase AuthKeycloakOktaAWS Cognito
📋 Before you start
💰 Salary by region
| Region | Junior | Mid | Senior |
|---|---|---|---|
| USA | $105k | $145k | $190k |
| UK | £65k | £90k | £125k |
| EU | €70k | €95k | €135k |
| CANADA | C$110k | C$150k | C$200k |
🎓 Certifications
🎯 Careers using JWT Tokens
⚖ Compare with
❓ FAQ
JWT vs sessions — when should I use stateless tokens instead of server-side sessions?
Sessions: server stores user state (Redis/DB), sends encrypted cookie to client. Pros: can revoke instantly, easy logout. Cons: doesn't scale — requires sticky sessions or shared state. JWT: client stores signed token, server validates signature only (no lookup). Pros: stateless, scales horizontally, good for mobile/SPA. Cons: can't revoke instantly (token lives until expiration). Best practice: Use JWT for APIs + SPAs with short expiry (15 min) + refresh tokens. Use sessions for monolithic web apps where sticky sessions OK.
What's the difference between HS256 and RS256, and which should I use?
HS256 (HMAC): symmetric — same secret signs and verifies. Pros: fast, simple. Cons: secret must be shared across all services (risky). RS256 (RSA): asymmetric — private key signs, public key verifies. Pros: public key can be shared safely, microservices don't need the secret. Cons: slower (RSA overhead). Rule: single monolith + co-located services = HS256 OK. Microservices / multi-tenant = RS256 mandatory. ES256 (ECDSA) is newer, faster than RS256, same benefits.
How do I implement refresh tokens to avoid long-lived JWTs?
Issue two tokens: (1) Short-lived access token (15 min, high risk), (2) Longer-lived refresh token (7 days, stored in httpOnly cookie). Flow: User logs in → server issues both tokens → client uses access token for requests → token expires → client sends refresh token → server validates + issues new access token. Never put refresh token in localStorage (XSS risk). Refresh tokens can be blacklisted in DB if early logout needed. Rotate refresh tokens: issue new refresh token with each refresh (old one invalidated).
Where should I store JWT tokens in the browser — localStorage, sessionStorage, or cookies?
localStorage: XSS vulnerable (JS can steal it), but survives page reload. sessionStorage: same XSS risk, clears on tab close. Cookies: can be httpOnly (JS-proof, only sent over HTTP), but must mitigate CSRF. Best practice: httpOnly, secure, sameSite=Strict cookie for refresh token (longer-lived). Access token: either httpOnly cookie (safest) or localStorage (acceptable if SPA uses CSP). Never put JWT in regular (non-httpOnly) cookies unless you want XSS stolen.
How do I revoke or blacklist JWT tokens before expiration?
JWTs are stateless — can't revoke instantly without a server check. Options: (1) Token blacklist (Redis set of revoked jti claims, checked on every request — defeats stateless purpose). (2) Short expiry + force refresh (15 min access token + refresh rotation). (3) Logout endpoint updates user's 'token_version' field in DB, client checks version on decode. (4) JWTs with low jti counter, increment on logout (stateless revocation). Most practical: short expiry + refresh rotation. Blacklist only for high-security (logout from all devices immediately).
What claims should I include in JWT payload, and what should I never put there?
Always include: sub (subject/user ID), iss (issuer), aud (audience/service), exp (expiration), iat (issued at). Include: roles, permissions, org_id. Never include: passwords, credit cards, PII like SSN/address. Remember: JWT payload is base64-encoded (not encrypted) — anyone can read it. Use JWE (JSON Web Encryption) if payload must be private. Keep payload small (sent with every request). If payload > 1KB, use opaque token + server lookup instead.
What are the common JWT security vulnerabilities, and how do I avoid them?
Critical: (1) 'none' algorithm — always reject alg=none. (2) Weak signing key — use strong secrets (32+ chars) for HS256, proper RSA for RS256. (3) Not validating exp — check expiration every decode. (4) Trusting unverified tokens — always verify signature server-side. (5) Storing in localStorage — use httpOnly cookies. (6) Algorithm confusion — specify expected algorithm when verifying (don't trust client's alg claim). (7) JWKS endpoint not cached — cache public keys with a 1-hour TTL to avoid lookups on every request.
Not sure this skill is for you?
Take a 10-min Career Match — we'll suggest the right tracks.
Find my best-fit skills →Find your ideal career path
Skill-based matching across 2,536 careers. Free, ~10 minutes.
Take Career Match — free →