Stateful and stateless authentication

In this article I am going to talk about two different ways of authentication: stateful and stateless authentication. If you have learnt about networking, you may already heard about stateful and stateless, but in this article I am going to give these two adjectives other meanings.

Stateful: You can revoke the authentication session on the IdP anytime.

Stateless: The session expiration time is set when the authentication token is released. You cannot revoke the session on the IdP.

Stateful authentication

How it works

In this model, you can easily imagine that if the session memory is deleted on the backend side, then the session reference Id, which the client is holding, is completely meaningless.


  • Easy to implement and manage for one-session-sever scenario
  • Session data can be changed later (assume that for a one-session-sever, no inconsistent problem)


  • Fail to scale: If the sessions are distributed in different servers, we need to implement a tracking algorithm to link a specific user session and the specific session sever. That means, once Bob’s session is handled by X server, then all Bob’s following requests must be handled by X server. This can be done by adding a tag to the client request in the proxy layer (e.g. HAProxy) before routing to the backend. The proxy layer using this tag to determine which backend server to route.
    Furthermore, if the session servers are deployed with duplication to have fail-over, the problem becomes more complicated since the 2+ peers duplicating each other must implement an algorithm to make sure the consistency of their sessions.
  • Difficult for 3rd party applications to use your credentials: In fact, this is also one of the “fail to scale” example, but I note it down separately since it is important. When a 3rd party application enables your users to login their website, the 3rd party application is not able to directly verify your users’ session (they are stored on your backend). The verification must be redirected to the credential servers. Therefore, there is more work between 3rd party application and the backend.

Stateless authentication

How it works

Stateless authentication stores the user session data on the client side (browser). The data is signed by the key of IdP to ensure the integrity and authority of the session data.

Since the user session is stored on the client side, the server only have the capability to verify its validity by checking whether the payload and the signature match.

id: 1234,
user: "kennethchoi",
FirstName: "Kenneth",
LastName: "Choi",
Expiration: 1525132799 // 2018-04-30T23:59:59+00:00
Signature (a string) using a specific algorithm and the private key to sign:


  • Easy to scale: Since the session data is stored on the client side, it does not matter which backend server the request is routed to, as long as all backend servers share the same private key, then all servers have the same capability to verify the validity of the session.
  • Good to integrate with 3rd party application: In the single sign-on protocols, the 3rd party applications and the IdP must be able to communicate with each other via user agents (browser). During the account linking process between 3rd party applications and IdP, IdP sends a signed message to the browser, and the browser redirects this message to the 3rd party applications. Using a pre-configured shared secrete, the 3rd party applications can determine whether the account linking (single sign-on) is valid by itself.


  • Relatively complex to implement for one-session-server scenario: The advantages of stateless authentication is scalability. However, it increases the technical complexity and it is not extremely useful when we only have one-session-server.
  • Session data cannot be changed until its expiration time: Suppose we want to add “Age” property to the session data above, probably we can ask the client to update it, but we cannot make sure the client does update it, since its previously session data is not expired yet, then the client still has the chance to make requests with old session data.

A brief comments on the stateful and stateless authentication

Improved stateless authentication: sliding session

  • Set the expiration time of user data to 24 hours (instead of one month).
  • Each time the session data is expired, the client issues a request (attached with a valid refresh token) to the server to renew the session data.

With this improvement, we can have the scalability and performance advantages of stateless authentication. Though we still cannot revoke the session data immediately, while we can forbid its lifetime extension by revoking the refresh token.


Software Engineer@Adobe; CS Graduate@Cornell