In the field of web development, I believe everyone is familiar with cookies and sessions. Both cookies and sessions are solutions for session retention technology. With the development of technology, the Token mechanism has appeared in front of us, but many developers are confused about the difference and usage scenarios of Token, Cookie and Session.
session 和 cookie
1. What is session and cookie
- First of all, we must know that the HTTP request is stateless, that is, we don’t know whether this request is related to the previous request. For example, when we log in to a system, after verifying the username and password, we don’t need to open each page of the system. The login operation is carried out, until we actively log out or log out over time; here in order to avoid access to each login, we need to use session and cookie;
- Cookie is a mechanism for saving user information on the client (browser); and there are some differences in the storage size of each browser, generally no more than 4KB;
- The session is saved on the server and can be used to record the state of the client. For example, we often use session to save the basic information and permission information of the client; after the user logs in for the first time, the server will create a session. When the browser visits again, You only need to find the customer's information from the session.
Second, the purpose of Cookie and Session
- We must know that we visit the website through the HTTP protocol or the HTTPS protocol. The HTTP protocol itself is a stateless protocol (that is, the server cannot distinguish which requests are from the same client). The business level involves the interaction between the client and the server (data can be shared between multiple pages on the same website). At this time, the server must maintain a conversational state in order to authenticate the user.
- Due to the stateless nature of HTTP, if you want to keep the conversation between the client and the server, you need other mechanisms to implement it, so Cookie and Session came into being.
- Normally, Session and Cookie are used together.
Token
1. Why is Token generated?
There will be a problem here. The server has to save session information of all users, and the overhead will be very high. If in a distributed architecture, you need to consider the issue of session sharing, and you need to do additional design and development. The information is saved in Redis for sharing; therefore, for this reason, some people consider whether the information can be saved by the client, it can be saved anywhere, and its security is guaranteed, so there is a Token.
2. What is Token?
- Token is a string of strings generated by the server, which can be regarded as a token for the client to request.
- When the client accesses the server for the first time, the server will use some encryption algorithms to generate a Token based on the unique userId passed in. The next time the client requests, it only needs to bring the Token. After the server receives the request, it will Verify this Token.
- Some companies will build a unified login system (single sign-on). The client first goes to this system to obtain Tokens, and then takes these Tokens to access other systems after verification; API Gateway can also provide similar functions, our company is like this, the client When accessing, first obtain the Token from the gateway, and only after the verification is passed, can you access the authorized interface, and re-token after a period of time.
- Token is commonly called "token", and its composition is:
- uid: the unique identity of the user;
- timestamp: current timestamp;
- sign: signature string to prevent third parties from forging data; the signature key is stored on the server side, and other people cannot know it;
- Other additional parameters.
3. Token-based authentication process
- The client uses the user name and password for authentication;
- The server performs identity verification after receiving the request (may also be a unified login platform, gateway);
- After the verification is successful, the server will issue a Token and return it to the client;
- After the client receives the token, it can store it (you can put it); every time it sends a request to the server, it must bring the token;
- Token will have an expiration time, and it needs to be verified again after expiration;
- When the server receives the request, it will verify the Token in the client's request. After the verification succeeds, it will respond to the client's request;
to sum up
- cookie：
- Saved in the browser, there is a size limit and a state;
- Because it is stored on the client, it is insecure and can be cleared manually;
- The cookie has an expiration time setting. If the expiration time is not set, it means that the cookie is the session time of the current browser. When the browser is closed, the cookie exists. If there is an expiration time, the cookie will be stored on the hard disk, and the browser will not affect the cookie when it is closed. Next time you open the browser, the cookie still exists;
- The cookie has a size limit of 4KB.
- Session: stored in the server, the server has resource overhead, which is not easy to implement in distributed and cross-system;
- Token: The client can save the Token anywhere, unlimited and stateless, which is good for distributed deployment.