How to understand the differences and connections between Session, Cookie, and Token

This article will introduce Session, Cookie, and Token from the perspective of the evolution of Web applications from traditional authentication to Token-based authentication.

A long time ago, Web applications were basically used for document browsing, such as online yellow pages. Since it was just browsing, the server did not need to record which documents a specific user browsed in a certain period of time. Each request was a new HTTP protocol, which was brand new to the server.

[[284843]]

Session-based authentication

With the rise of interactive Web applications, such as shopping websites that require login, a new problem has arisen, which is to record which users have logged into the system and what operations have been performed, that is, to manage sessions (what is a session? Simply put, if the user needs to log in, then it can be simply understood as a session, if not, then it is a simple connection.), for example, different users add different products to the shopping cart, which means that each user must be distinguished. Because HTTP requests are stateless, a solution has been devised, which is to assign a session identifier (Session id) to each user. Simply put, it is a random string that will not repeat and is not easy to find a pattern to imitate, so that each user receives a different session identifier. Every time a user initiates an HTTP request from the client to the server, this string is sent together, so that the server can distinguish who is who. As for how the client (browser) saves this "identity identifier", it is generally defaulted to use Cookies, and this session identifier (Session id) will be stored in the client's Cookie.

Although this solves the problem of distinguishing users, it raises a new problem, that is, each user (client) only needs to save his own session id, while the server needs to save the session ids of all users. If the number of users accessing the server increases, it will need to save tens of thousands or even tens of millions of sessions, which is an unacceptable overhead for the server. For example, the server is a cluster consisting of two servers. Xiao Ming logs in to the system through server A, and the session id will be saved on server A. What if Xiao Ming's next request is forwarded to server B? Server B does not have Xiao Ming's session id.

Someone may say, if Xiao Ming is always logged in on server A (sticky session) when logging in, wouldn't this solve the problem? But what if server A hangs up? Xiao Ming's request will still be forwarded to server B.

In this case, the only way to do session replication and sharing between clusters is to copy the session ID between two machines, as shown in the figure below, but this poses a huge challenge to the server's performance and memory.

Therefore, the idea of ​​storing all user sessions in a centralized manner came to mind, and the cache service Memcached came to mind. Since Memcached is a distributed memory object cache system, it can be used to achieve session synchronization. The session id is stored in a centralized server, and all servers access the data in this place, thus avoiding the replication method. However, this "collection of thousands of favors in one" makes a single point of failure possible. That is, if the server responsible for storing the session fails, all users have to log in again, which is difficult for users to accept.

Then we simply cluster the servers storing the Session to increase its reliability and avoid single point failures. However, no matter what, problems caused by the Session keep emerging.

So some people are thinking, why must the server save the session? Can't each client save it? But if the server does not save these session IDs, how can it verify that the session ID sent by the client is indeed generated by the server? If it is not verified, the server cannot determine whether it is a legitimate logged-in user. Yes, the problem here is verification. Session is just a solution to this verification problem. Are there other solutions?

Token-based authentication

For example, Xiao Ming has logged into the system, and the server sends him a token, which contains Xiao Ming's user id. When Xiao Ming accesses the server again through an HTTP request, he can just bring the Token through the HTTP header.

The server needs to verify that the Token is generated by itself and not forged. If anyone can forge it without verification, then there is no essential difference between this token and session ID. How can we prevent others from forging it? Then sign the data. For example, the server uses the HMAC-SHA256 encryption algorithm, plus a key known only to the server, to sign the data, and send the signature and data together as a Token to the client. After receiving the Token, the client can store it, such as in a cookie or Local Storage. Since the key is unknown to any user except the server, the token cannot be forged.

In this way, the server does not need to save the Token. When Xiaoming sends the Token to the server, the server uses the same HMAC-SHA256 algorithm and the same key to calculate the signature of the data again and compare it with the signature in the Token. If they are the same, it means that Xiaoming has logged in, that is, the verification is successful. If they are not the same, then it means that the request is forged.

In this way, the server only needs to generate a token, but does not need to save it. It only needs to verify the token, which achieves the goal of exchanging time for space (CPU computing time for session storage space). Without the limitation of session id, when the number of user visits increases, it is easy to expand horizontally by simply adding machines, which greatly improves scalability.