Stop Using JWTs

This opinion piece, published as a GitHub Gist by developer samsch and surfaced on Hacker News, makes the case that JSON Web Tokens (JWTs) are overused and frequently misapplied — particularly for web session management — and that developers should stop reaching for them by default. JWTs have become a near-ubiquitous tool in modern web development, popularized by the rise of stateless APIs, microservices, and single-page applications. A JWT encodes a signed payload (typically user identity and claims) that can be verified without a round-trip to a database, which made them attractive for distributed architectures. They are issued by an authentication server, passed to the client, and then presented with each subsequent request. However, this convenience comes with a set of structural problems that critics — including this author — argue are routinely underappreciated. The core issue is revocation. Because JWTs are self-contained and stateless, a server cannot invalidate a token before its expiry without introducing a token blocklist or some other server-side state — at which point much of the stateless benefit evaporates. In practice, this means that if a user logs out, changes their password, or has their account compromised, their existing JWT may remain valid until it naturally expires. For short-lived tokens this window is narrow; for long-lived tokens it can be significant. A second concern is storage. JWTs must live somewhere on the client: localStorage exposes them to XSS attacks, while httpOnly cookies — the safer option — are available regardless of token format, meaning you gain nothing over a traditional opaque session cookie. The argument that JWTs avoid cookies is technically true but conflates token format with transport mechanism. Third, JWTs carry a footprint cost. They encode all claims directly in the token, which can grow large, adding overhead to every request. A conventional session ID is a short random string; the server holds the session data. The JWT pattern moves that data to the client and to the wire. Fourth, the JWT specification itself has a fraught history. The alg:none vulnerability, RS256/HS256 confusion attacks, and weak default validation in many libraries have caused real-world security incidents. While mature libraries have addressed these, the surface area for implementation error remains broader than with opaque session tokens backed by a simple database lookup. The article's recommendation — inferred from the title and the well-established contours of this debate — is that for the vast majority of applications, especially monoliths and moderately scaled services, traditional server-side sessions with an opaque token stored in an httpOnly cookie are simpler, easier to reason about, easier to revoke, and no less performant. Stateless JWT authentication makes sense in narrow contexts: true service-to-service auth, short-lived access tokens in OAuth flows, or cases where the verifying party genuinely cannot reach a shared session store. For ordinary user session management, they are a solution in search of a problem. This argument is not new — it has circulated in developer communities for years — but it resurfaces periodically because JWT adoption continues to outpace careful evaluation of whether the tradeoffs are appropriate. The Hacker News discussion likely drew attention because the framing is direct and the gist format signals a practitioner perspective rather than an academic treatment. For developers building authentication systems, the piece is a useful prompt to revisit first-principles questions: What does the application actually need? Who verifies the token? Can sessions be stored server-side? The answers will often point back toward the simpler path.