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

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.

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.

Advantages

• 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)

Disadvantages

• 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).

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.

Payload:
{
  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:
XxxxXXXxxxxXXXXXXxxxxXX

Advantages

• 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.

Disadvantages

• 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.

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.

Conclusion

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.