I'm trying to clarify the relationship between sessions, JWTs, and stateless systems. A session seems to be a period of interaction in which some state is carried between requests. Traditionally, that state is stored on the server and the client sends a session ID, making the application stateful. A JWT can carry claims in the token itself, so the server can validate each request without looking up a session record. Does that make a JWT an alternative type of session, or are JWTs and sessions fundamentally different concepts?
4 Answers
Calling a JWT itself a session is mostly a terminology issue. A session is the broader concept of maintaining continuity between requests, while a JWT is a mechanism for carrying authenticated information between those requests. Depending on the design, the JWT can participate in a session, replace a server-side session lookup, or simply be used as a short-lived access token for an API.
A JWT is a token format, not a session by definition. It is commonly used for authentication and authorization because it can carry signed claims that a server verifies locally. You can use a JWT as a session mechanism, but that is one application of the format rather than what JWT inherently means.
The key distinction is where the ongoing state lives. With a server-side session, the server stores the state and the client sends an identifier. With a self-contained JWT, the client sends the claims on every request and the server does not need a session lookup. That can make request handling more stateless from the server’s perspective, although the client still retains and resends state.
JWTs are usually best kept small: an identity, issuer, expiration time, and perhaps roles or scopes. They are signed so they cannot be modified unnoticed, but they can still be copied and replayed. Revoking one before it expires is also difficult unless you add a denylist or use short lifetimes and a separate refresh-token strategy.
That is why frequently changing information generally should not be placed in the JWT. If permissions or session details change, an already-issued token may continue to contain the old claims until it expires.