Ten years of JSON Web Token and preparing for the future

What JWT / JOSE Actually Provide

• JWT is described as “JSON plus cryptographic proof”: a JSON payload with a signature or encryption.
• It’s part of the broader JOSE family (JWS, JWE, JWK) – generic, web-friendly containers for crypto primitives.
• Main value: a standardized, language-agnostic way to pass signed/encrypted data instead of bespoke formats.

JWT vs Cookies / Sessions

• Many like JWT for server–server or microservice scenarios, especially with asymmetric keys (issuer holds private key; consumers only see public key).
• For browser auth, several argue JWT mostly reimplements cookies/sessions, often with more complexity and larger payloads.
• Others push back that:
  • Cookies are domain-bound and not inherently signed; frameworks often add signing/encryption but that’s not standardized.
  • JWTs can be shared across domains/servers and include claims for both authentication and authorization in one object.
• A common pattern: put the JWT itself inside an HttpOnly, SameSite cookie, effectively layering standards.

Complex Authorization & Claims

• Trying to encode rich permissions (beyond simple scopes) directly into JWTs quickly leads to very large tokens or centralized, brittle role logic.
• One workaround mentioned: bitmask-based permissions to keep tokens compact, but this fails once you need per-object distinctions.
• Consensus in the thread: authorization models are highly domain-specific; general standards tend to become painful or heavyweight.

Critiques: Size, Misuse, and Security Footguns

• Complaints about JWTs being “fat” and overused where a random opaque session ID would suffice.
• Common misuses:
  • Treating base64 encoding as encryption.
  • Putting PII (name, email) in unsigned or merely signed tokens and sending them to third parties.
  • Poor library defaults (historical alg=none, algorithm confusion, insecure algorithms), leading to real-world CVEs.
• Some argue these are spec-level flaws (too many options, unsafe modes); others say most serious issues are now well-understood and avoidable.

Alternatives and Competing Formats

• Many situations are said to be better served by:
  • Classic server-side sessions with random 32-byte IDs.
  • Custom Protobuf/MessagePack + authenticated encryption (e.g., libsodium).
  • Macaroons or specialized formats for caveats/delegation.
• Paseto is discussed as a “safer JWT” with fixed, modern primitives; supporters emphasize reduced footguns, skeptics see it as NIH with limited ecosystem and unclear advantages.
• Other proposals (Biscuit, Zanzibar, Coze) appear as niche or experimental options for specific authorization problems.

Revocation, Logout, and Token Lifetimes

• Core tension: stateless tokens vs real-time revocation and role changes.
• Approaches discussed:
  • Short-lived access tokens (minutes) plus longer-lived refresh tokens (OIDC-style).
  • Revocation lists in memory/Redis keyed by token ID or “earliest valid issued-at” per user, propagated via pub/sub or DB notifications.
  • “Logout from all devices” by bumping a per-user minimum-iat timestamp.
  • Global key rotation to invalidate all tokens for major incidents.
• Some argue explicit revocation is rare enough that these mechanisms work well; others say in many enterprise/collaboration/financial contexts, immediate revocation is routine and necessary, making simple cookie-backed sessions more attractive.

Use Cases and Limits

• Defended use cases:
  • Edge/ CDN workers authorizing cached responses without a DB round-trip.
  • App clients that lack cookie jars but still need interoperable auth.
  • Serverless/microservice architectures that want locally verifiable claims.
• Skeptical voices say that for most monolithic or typical web apps, cookies + sessions (with good security flags) are simpler, easier to revoke, and operationally safer.

Standards and Guidance

• OAuth 2.0 itself does not require JWT, but OIDC and several OAuth extensions (access token profiles, DPoP, JAR) effectively make JWT the default in many ecosystems.
• The article is noted as primarily pointing to updated “JWT Best Current Practices” guidance that tries to codify safer algorithms and usage patterns.