JWT | What It Is & How I Use It

JWT, JSON Web Token, is the compact, self-contained token format that powers authentication in most modern web applications. When a user logs in, the server creates a JWT containing their identity and permissions, signs it cryptographically, and hands it to the client. On every subsequent request, the client sends that token back, and the server verifies the signature without needing to look anything up in a database. That stateless nature is what makes JWTs so powerful for distributed systems, any server in a cluster can validate the token independently. I use JWTs in virtually every custom application I build. Whether the auth provider is Clerk, Auth0, or a custom implementation, JWTs are the format carrying the session data between client and server.

How JWT Changed Everything

Before JWTs became the standard, web applications used server-side sessions almost universally. When a user logged in, the server created a session record in memory or a database, generated a random session ID, and stored it in a cookie. Every request required a round-trip to the session store to look up who the user was. This worked fine for monolithic applications running on a single server, but it became a nightmare at scale. Load balancers needed sticky sessions, session stores became single points of failure, and microservices had no clean way to share authentication state. JWT was formalized as RFC 7519 in May 2015 by Michael Jones (Microsoft), John Bradley, and Nat Sakimura. The specification built on earlier work from the JOSE (JSON Object Signing and Encryption) working group at the IETF. Auth0, the identity company founded by Eugenio Pace and Matias Woloski in 2013, was instrumental in popularizing JWTs through their jwt.io debugger tool and extensive developer education. By 2017, JWTs had effectively replaced server-side sessions as the default authentication mechanism for SPAs and mobile applications.

One Thing Most People Miss

The most common mistake developers make with JWTs is treating them as encrypted. They are not. A JWT is base64-encoded, which means anyone can decode the payload and read its contents, it is not secret. The signature only guarantees that the payload has not been tampered with, not that it is hidden. This means you should never put sensitive data like passwords, credit card numbers, or personal health information in a JWT payload. The second critical misunderstanding is about token revocation. Because JWTs are stateless, there is no built-in mechanism to invalidate one before it expires. If a user's account is compromised and you need to revoke their access immediately, a JWT with a 24-hour expiration will remain valid for up to 24 hours unless you implement a token blacklist, which reintroduces the server-side state that JWTs were supposed to eliminate. The practical solution is to use short-lived access tokens (5-15 minutes) paired with longer-lived refresh tokens, and to store refresh tokens server-side where they can be revoked instantly. This hybrid approach gives you the performance benefits of stateless validation for most requests while retaining the ability to cut off access when needed.