preface
I have read many articles of the same type before, and there are different opinions on Cookie and Session. Some people say that there is a Cookie before there is a Session, and some people say that there is a Cookie after the existing Session. I also say my understanding, hope to be helpful to you. Note: Readers are required to have a basic understanding of cookies /Session/ Tokens.
The Cookie and Session
Before WE get to those two,Start with HTTP, which is a stateless protocol.How do you understand that? There is no connection between two consecutive requests. The advantage of this is that it is fast, but the disadvantage is that in order to associate two pages under the same domain name, you have to use certain tools and tools.This brings us to cookies and sessions.• First, the client sends an HTTP request to the server; • After the server accepts the client request, it establishes a Session and sends an HTTP response to the client. This response header contains the set-cookie header. The header contains the SessionId; • On the second request from the client, if the server gives set-cookie, the browser will automatically add Cookie to the request header; • The server receives the request, dissolves the Cookie, verifies the information, and returns a response to the client after the check is successful.
To sum up, Session is a bit like user information file table, which contains user authentication information and login status and other information, while Cookie is the user pass.
Token
Token, also known as Token, consists of uid+time+sign(+ fixed parameters) : • UID: indicates the unique identity of the user • time: indicates the timestamp of the current time • sign: Signature, compressed into a fixed hexadecimal string using hash/encrypt to prevent third-party malicious concatenation • Fixed parameters (optional): Some common fixed parameters are added to the Token to avoid repeated library checks. Token authentication is similar to temporary certificate signature and is a server-side stateless authentication mode, which is suitable for REST API scenarios. Stateless means that the server does not store authentication data. The Token is stored in LocalStorage, Cookie, or SessionStorage on the client. Typically stored in a database on a server.
Token Authentication Process
The Token authentication process is similar to that of cookies. • After the user successfully logs in, the server returns the Token to the client. • Data received by the client is saved on the client. • The client accesses the server again and places the Token into the Headers. • Filter is used for verification on the server. If the verification succeeds, the request data is returned; if the verification fails, an error code is returned.
The difference between Cookie, Session and Token
Token can resist CSRF attack, Cookie+Session cannot. Let’s assume a scenario: the user is logging in to the webpage of the bank, and logs in to the webpage of the attacker Tom. Bank web pages are not protected against CSRF attacks; Tom places a form on the web page that is submitted SRC www.bank.com/api/transfe… If Session+Cookie is used, the money in the card will have been transferred by Tom when the user opens the webpage. Post requests initiated by the FORM are not restricted by the same origin policy of the browser. Therefore, cookies of other domains can be used to send POST requests to other domains, forming CSRF attacks. At the instant of a POST request, the Cookie is automatically added to the request header by the browser. However, Token is a Token specially designed by developers to prevent CSRF. The browser does not automatically add the Token to the Headers, and an attacker cannot access the user’s Token. Therefore, the submitted form cannot be filtered by the server and thus cannot be attacked.
Session and Token in distributed mode
We already know that sessions are stateful and generally stored in server memory or hard disk. When servers are distributed or clustered, sessions face load balancing problems. • Load balancing in the case of multiple servers, it is difficult to check whether the current user is logged in because the multiple servers do not share sessions. This problem can also be solved by storing sessions on a single server, but the load balancing effect is not completely achieved. There’s a way around it but it’s messy. The Token is stateless, and all user information is stored in the Token string. • The client logs in and transfers the information to the server, which encrypts the user information (Token) to the client, and the client stores the Token in a container such as LocalStroage. The client passes the Token on each access, and the server decrypts the Token to know who the user is. Through CPU encryption and decryption, the server does not need storage Session to occupy storage space, which is a good solution to the problem of load balancing multiple servers. Note: This method is called JWT(Json Web Token).
conclusion
• A Cookie is like a token with a SessionId stored on the client and usually added automatically by the browser. • The Session is stored on the server, which can be understood as a list of states with a unique identifier SessionId, usually stored in cookies. After receiving the Cookie, the server parses the SessionId and searches the Session list to find the corresponding Session. The Session also relies on cookies. • Token is a stateless Token that needs to be added manually by the developer. The user information is encrypted into the Token string. After receiving the Token, the server decrypts it to find out which user it is. • JWT is just a cross-domain authentication scheme.