JWT authentication without mythology — rotations, revocation, and session ergonomics
Symmetric versus asymmetric verification, JWKS fleets, leaky storage pitfalls, and when opaque cookies outperform bearer tokens.
JSON Web Tokens package claims plus optional integrity protection (typically digital signatures) into Base64-encoded segments—they are usually signed, not encrypted, despite outward randomness comforting the untrained eye.
Misunderstood JWTs fueled recurring incident clusters: sprawling claim payloads (roles arrays mirroring entire relational explosions), indefinite trust lacking rotation rehearsals, verifying “signature good” without constraining aud or iss, stuffing regulated PII into payloads, handing symmetric HS256 secrets anywhere near browser bundles where anyone can forge tokens trivially upon leak.
Signing versus secrecy
Signatures answer tamper-evidence and origin—“who minted this blob?” Confidentiality asks different cryptographic questions altogether. Sensitive payload protection requires deliberate encryption constructions (JWE) or narrower patterns coupling short-lived identifiers to server-held records.
HS256 monoculture
Symmetric secrets verify cheaply behind a solitary API façade until any leak compromises every verifier concurrently. Operational discipline mandates tight KMS integration, audited rotation rehearsals, and environment isolation so compromised staging material never mints prod-typed claims.
Asymmetric verification fleets
RSA/ECDSA signers exposing JWKS endpoints offload verification cost to satellites while simplifying rotation choreography (overlap two valid keys). Complexity migrates toward correct caching, backoff on unknown keys, telemetry when verification skew emerges after deploy reorderings.
Failure mode: JWKS TTL set to eternity so key rollovers never propagate—simulate thundering bursts after kid churn.
Revocation realism
Marketing “stateless forever” melts under forced logout, insider compromise policy, nuanced partial permission revocations, compliance retention. Compose:
| Technique | Fits when |
|---|---|
| Short TTL + refresh | Controlled device footprint |
| Server-side revocation snapshots | Sensitive actions needing kill switches quickly |
| Opaque cookie sessions | Web threat model favors minimizing JS-readable secrets |
Treat refresh issuance as perilous as credential minting—it is not ceremonial plumbing.
Bearer headers versus cookies
Browser SPAs adored Authorization: Bearer ergonomics juxtaposed tragically beside localStorage persistence under XSS umbrellas. Prefer Secure, HTTP-only cookies guarded by disciplined CSRF strategy unless native/mobile constraints justify bearer surfaces.
Authentication is layering: TLS transport, hardened storage surfaces, audited issuance pipelines, revocation tactics, anomaly detection—not a single triumphant acronym.
Related writing
- JWT Access and Refresh Token StrategyDesign short-lived access tokens and rotating refresh-token sessions with revocation, browser protections, and key rotation.
- Hashing vs Encryption vs Encoding — The Differences Developers Must UnderstandA production-minded map of encoding, hashing, and encryption—salts, passwords, JWTs, Base64 myths, interview answers, and the mistakes reviewers catch.
- Fix Nodemailer TLS Certificate Hostname ErrorsWhat ERR_TLS_CERT_ALTNAME_INVALID means when Nodemailer connects to an SMTP server, why it happens, and how to fix it without disabling certificate verification.