Stateful and stateless authentication

Stateful authentication

Stateful authentication is commonly used in many applications, especially for applications that do not require scalability too much.

How it works

Stateful session is created on the backend side, and the corespondent session reference Id is sent to the client. Each time the client makes a request to the server, the server locates the session memory using the reference Id from the client and finds the authentication information.


  • Revoke the session anytime
  • 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)


  • Increasing server overhead: As the number of logged-in users increases, the more server resources are occupied.
  • 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

Stateless authentication is used to solve the disadvantages of stateful authentication. They are quite different and are used in different scenarios.

How it works

Note: Here I am not talking a specific authentication protocol, while I am trying to give an simple example to illustrate the ideas. If you are looking for concrete industrial standards, please refer to OpenID Connect and JSON Web Token (JWT).

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:


  • Lower server overhead: The great number of session data does not store on the server side. We can store more user properties on the client-side session data to reduce the number of database access without worrying the memory overhead on the server.
  • 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.


  • Cannot revoke the session anytime: Since the user session is stored at client side, the server does not have any rights to delete the session.
  • 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

It is obvious that they have opposite pros and cons. Stateless authentication is great, but it takes time to implement and it contains some restrictions. In the following section I am going to share an improved version of stateless authentication that can eliminate some disadvantages.

Improved stateless authentication: sliding session

  • Assign clients the permission (send the clients a unique refresh token) to request an extension lifetime of session data.
  • 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.


In this article, I illustrate the ideas of stateful and stateless authentication. I do not list concrete protocols for discussion since those protocols may contain many other security design that will blur out the focus between the differences between stateful and stateless authentication. I simplify the examples here for better understanding. If you are interested in the industrial design, you should definitely go for the specification of some authentication protocols.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kenneth Choi

Kenneth Choi

Software Engineer@Adobe; CS Graduate@Cornell