In web applications, HTTP requests are stateless. That is: after the user initiates a request for the first time, establishes a connection with the server and logs in successfully, in order to avoid having to log in every time he opens a page, cookies and sessions appear.
Cookie is a mechanism for client to save user information, which is used to record some user information, and it is also a way to realize session. The amount of data stored in cookie is limited, and all of them are stored in the client browser. Different browsers have different storage sizes, but generally no more than 4KB. Therefore, using cookies can only store a small piece of text information.
For example: log in to the website, enter the user name and password to log in today, and then open it the next day. In many cases, it will be opened directly. One mechanism used at this time is cookie.
Session is another mechanism to record customer status. It is a data structure stored in the server (mainly storing session ID and session content, but also containing a lot of user-defined content, such as user basic information, permission information, user organization information, fixed variables, etc.). This data can be saved in clusters, databases and files for tracking users The state of the system.
When the client browser accesses the server, the server records the client information in some form on the server. This is the session. When the client browser accesses again, it only needs to find the status of the client from the session.
After the user logs in for the first time, the browser will send the user information to the server, the server will create a session ID for the user, and return the session ID to the browser in the response content (cookie), and the browser will save the data locally. When the user sends the request again, the browser will automatically carry the cookie data stored in the last request to the server.
After receiving the request information, the server will determine which user is currently through the session ID in the data requested by the browser, and then obtain the session data of the user in the session library according to the session ID and return it to the browser.
For example, after adding products to a shopping cart, the client can know which products are added, while the server can tell which products are added. Therefore, session is also used to store some information.
If the cookie mechanism determines the identity of the customer by checking the “pass” on the customer, then the session mechanism confirms the identity of the customer by checking the “customer details” on the server. Session is equivalent to a client file created by the program on the server. When a client visits, he only needs to query the client file table.
After the session is generated, as long as the user continues to access, the server will update the last access time of the session and maintain the session. To prevent memory overflow, the server will delete sessions that are not 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 will be invalid automatically.
HTTP requests are all docked in stateless form. That is, the HTTP server does not know whether this request is associated with the previous request. So there is the introduction of session, that is, both the server and the client save a piece of text, and each time the client initiates a request, the server will know whether the client has initiated a request.
In this way, the client frequently sends request data to the server, and the server frequently goes to the database to query and compare the user name and password to judge whether the user name and password are correct or not. The storage of session needs space, and frequent query of database causes great pressure on the server.
In this case, token is generated by application.
Token is a string generated by the server as a token for the client to request. When the client visits the server for the first time, the server will generate a token according to the unique ID of userid, use some algorithms and add the key, and then encode it through Base64 and return it to the client. The client will save the token (which can be saved locally in the form of database or file). In the next request, the client only needs to bring the token. After receiving the request, the server will use the same algorithm and key to verify the token.
The simplest token is composed of uid (user’s unique identity), time (time stamp of current time), sign (signature, which is compressed into a certain length of hexadecimal string by hash algorithm from the first few bits of token + salt, which can prevent malicious third party from splicing token request server).
Using token based authentication method, there is no need to store user login records in the server. The general process is as follows:
- The client uses the user name and password to request login
- The server receives a request to verify the user name and password
- After verification, the server will issue a token and send it to the client
- After receiving the token, the client can store it, for example, in the cookie or database
- Each time the client requests resources from the server, it needs to bring the token issued by the server
- The server receives the request, and then verifies the token in the client request. If the verification is successful, it returns the requested data to the client
When the app logs in, it sends the encrypted user name and password to the server, and the server verifies the user name and password. If it is successful, in some way, for example, it randomly generates a 32-bit string as a token, stores it in the server, and returns the token to the app. In the future, when the app requests, it should take the token with it wherever it needs to verify, and then the server verifies the token, and successfully returns the required password If it fails, return an error message and ask him to log in again.
For the same app, the same mobile phone currently has only one token; the mobile phone app will store a currently valid token. A valid period is set for the token on the server, and the token and valid period are verified every time the app requests.
The following example can be well understood:
“Give me a pancake (token, I’m the one who sells cold noodles at the opposite stall, scope credit)” “OK.”
“I’m the one who sells roasted and cold noodles at the opposite stall. I’ll pay for them on credit.”
“Add an egg (token, I’m the one who sells cold baked noodles at the opposite stall, scope credit)” OK
You end up with a plain pancake and two eggs
If the server restarts or for other reasons, the saved token on the server is lost. Then the user needs to login and authenticate again.
“Give me a pancake (token, I’m the one who sells cold noodles at the opposite stall)” that I haven’t seen you. ‘