In Web applications, HTTP requests are stateless. That is, after a user initiates a request for the first time, establishes a connection with the server, and successfully logs in to the server, the status is not recorded. To avoid having to log in every time you open a page, cookies, sessions.

Cookie

Cookie is a mechanism for the client to save user information, which is used to record some user information and also a way to realize the Session. Cookies store a limited amount of data and are stored in the client browser. Different browsers have different storage sizes, but generally no more than 4KB. So using cookies can actually store only a small piece of text information.

For example: login website, today entered the user name and password login, the next day in many cases directly opened. One mechanism used at this point is cookies.

Session

Session is another mechanism for recording client status. It is a data structure stored on the server (mainly storing the SessionID and Session content, but also contains many customized contents such as: Basic user information, authority information, user organization information, fixed variables, etc.), this data can be stored in clusters, databases, files, used to track the status of users.

When the client browser accesses the server, the server records the client information in some form on the server. So that’s Session. The client browser only needs to look up the client’s status from the Session when revisiting.

After a user logs in for the first time, the browser sends the user information to the server. The server creates a SessionId for the user and returns the SessionId in the Cookie to the browser. The browser saves the data locally. When the user sends a request again, the browser automatically carries the Cookie data stored in the last request to the server.

After receiving the request information, the server determines the current user based on the SessionId in the data requested by the browser, and then obtains the user’s Session data from the Session library according to the SessionId and returns it to the browser.

For example, when items are added to the shopping cart, the client can know which items are added, and the server can tell which items are added. In this case, the Session is used to store information.

If the Cookie mechanism determines the identity of a customer by checking the “pass” on the customer, the Session mechanism determines the identity of the customer by checking the “customer list” on the server. A Session is a client file created by the program on the server. When a client visits the server, it only needs to query the client file table.

After a Session is generated, the server updates the last access time of the Session and maintains the Session as long as the user continues to access the Session. To prevent memory overflow, the server removes sessions that have not been active for a long time from memory. This time is the Session timeout. If the server is not accessed after the timeout period, the Session is automatically invalidated.

Token

HTTP requests are connected in stateless form. That is, the HTTP server does not know whether this request is related to the previous one. Hence the introduction of the Session, where both the server and the client keep a piece of text, and the client carries it with it every time it makes a request, so the server knows if the client made a request or not.

As a result, the client frequently sends data requests to the server, and the server frequently queries the user name and password in the database and compares them to determine whether the user name and password are correct. However, the storage of Session needs space, and frequent query of database brings great pressure to the server. In this case, Token is applied.

A Token is a string generated by a server as a Token for a client to request. When the client accesses the server for the first time, the server generates a Token based on the unique identifier userId, uses some algorithms, and adds the key to the Token. After encoding it in BASE64, the Token is returned to the client, and the client saves the Token (either locally through a database or file). The next time the client requests the Token, the server will use the same algorithm and key to verify the Token after receiving the request.

The simplest tokens consist of: UID (the unique identity of the user), time(the timestamp of the current time), and sign(the signature, which is a hexadecimal string compressed by hashing the first few digits of the Token plus salt to prevent malicious third parties from concatenating Token requests to the server).

With token-based authentication, there is no need to store a user’s login record on the server. The general process is like this:

  • The client requests login using the username and password
  • The server receives a request to verify the user name and password
  • After the authentication succeeds, the server issues a Token and sends the Token to the client
  • After receiving the Token, the client can store it, for example, in a Cookie or cache
  • Each time a client requests resources from the server, it must carry a Token signed by the server
  • The server receives the request and verifies the Token in the request. If the verification succeeds, it returns the requested data to the client

If it helps you, give it a thumbs up