Should I use JWTs for authentication tokens?

Original Article ↗ Hacker News Discussion ↗

Scope of JWT Use

  • Many argue JWTs are overkill for simple, single-app web logins; classic server-side sessions are easier, safer, and well-supported by frameworks.
  • Others stress JWTs shine when:
    • Multiple services or domains must share auth (microservices, federated “service architectures”).
    • External IdPs (Azure AD, Auth0, Cognito, Keycloak, OIDC) are used and apps just validate tokens.
    • Edge components or API gateways need to cheaply drop unauthenticated traffic (DDoS mitigation).
    • Machine-to-machine, zero-trust-ish, or geographically distributed systems need decentralized verification.

Revocation, Logout, and Session Semantics

  • Core criticism: stateless JWTs make “real” logout and targeted revocation hard.
    • To revoke, you need allow/deny lists, per-user “issued-not-before” timestamps, or similar state → you’re back to a database/cache anyway.
    • If you only delete the token client-side, a stolen token remains valid; some call this a non-functional logout.
  • Defenses:
    • Use short-lived access tokens plus revocable refresh tokens.
    • Accept that revocation is coarse (“log out everywhere”) and not per-token.
    • For many business cases, a few minutes of extra access after compromise is considered acceptable.

Security and Implementation Complexity

  • Critics: JWTs are easy to misconfigure (alg=none, algorithm confusion, weak algorithms, misused encryption); safe use requires careful choices of alg, claims, key rotation, and library behavior.
  • Alternatives mentioned: opaque session IDs, PASETO, macaroons, custom signed tokens, or “JWT-as-opaque-token” where you never inspect claims.
  • Supporters: mature libraries and OIDC profiles mitigate many pitfalls if used as intended; JWT is just a signed claims format.

Sessions and Opaque Tokens

  • Pro-session side:
    • Simpler mental model; revocation and “logout everywhere” are straightforward.
    • DB or cache lookups per request are cheap for most sites; SPOF and scaling concerns are often premature.
  • Pro-JWT side:
    • No central session store; services only need signing keys.
    • Easier horizontal scaling and mockability; good fit with existing OAuth2/OIDC tooling.

Overall Sentiment

  • Strong consensus that “JWT everywhere for web sessions” is often unnecessary and leads to subtle bugs.
  • Equally strong pushback against absolute “never use JWT”: many see them as the right tool in distributed, multi-service, or third‑party‑IdP contexts.
  • The dominant takeaway: JWT vs sessions is a trade-off; the right answer is highly context‑dependent.