We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

Stateless vs. Stateful Authentication

Whenever a web server receives a request, it first needs to answer:

Is this request coming from an authenticated user?

Requests typically carry proof-of-authentication through stateless tokens or stateful sessions.

Stateless Authentication

Every request carries a credential that the server can validate without looking up a server-side session record. Typically:

  1. After successful login, the server issues a signed token to the client.
  2. The client sends the signed token with each request.
  3. The server accepts or rejects the request based on the token without loading a session record.

Sure, the server may still load user data, but "stateless" means the actual token validation doesn't depend on any stored session state. Many stateless systems use bearer tokens encoded as JWTs, and anyone who gets ahold of one can use it until it expires.

To be fair, a JWT doesn't automatically make a system stateless, the server can still check it against stored state, but that sometimes defeats the purpose of it being a JWT in the first place.

Stateful Authentication

The server remembers you. Typically:

  1. After successful login, the server creates a session record and sends a secret session identifier to the client
  2. The client sends the secret session identifier with future requests.
  3. The server accepts or rejects the request after checking if the session identifier maps to a valid session record (usually in a database or in-memory store).

Web apps usually carry the session identifier in a cookie.

Pros and Cons

Stateless token validation:

  • Avoids a server-side session lookup during token validation (simplifies scaling and reduces latency)
  • Makes immediate per-token revocation harder (unless it also checks shared state)

Stateful sessions:

  • Require a session store that all application instances can consult (can be slower and more complex to scale)
  • Allow the server to easily revoke a session immediately by invalidating its record