Should I use JWTs for authentication tokens?

Original Article ↗ Hacker News Discussion ↗

JWTs as authentication tokens are praised for being easy to implement, stateless, and well-aligned with OAuth2/OIDC and microservice architectures, but they draw heavy criticism for complicating logout, revocation, and security when used as general session storage. Many argue that for typical monolithic or small-scale web apps, traditional server-side sessions or opaque tokens stored in a database are simpler, safer, and “good enough,” with JWTs best reserved for cross-service, third‑party, or high‑latency scenarios. A recurring theme is that the real question is not “JWT or not,” but whether your concrete requirements—such as distributed auth, SSO, and revocation guarantees—justify the extra complexity of stateless tokens.

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.