In previous interview records, I saw another knowledge point that I was asked many times, that is, what is the difference between cookie, session and token? If I ask you now, I wonder if you can make it clear.

Today is not only to sort out the differences between the three, more important is to really understand the role and connection between the three.

Cookie, session, and token

The same goes for the Internet, where things are often created to solve a problem.

In the final analysis, cookies, sessions and tokens all revolve around one point: identity authentication.

Why certification

Very simple, for example, e-commerce shopping website requires login. After entering the account password and clicking login, a session session is generated for the server, just like a conversation between you and me. I remember you according to your name, words and appearance. So the server needs to be able to remember you, it needs to be able to separate people from each other.

However, since HTTP is stateless, users who have logged in can’t save their status through the protocol layer, so the server still doesn’t know who you are the next time you make a request.

What can be done?

Session

When the server receives a login request, it generates a session ID and returns it to the client. The client carries the session ID with it when requesting the login request next time. In this case, each client request corresponds to its own session ID, and the service knows how to distinguish between them.

Cookie

The session between the client and server is generally managed using cookies.

The service writes the Session ID (PHPSESSID= 028A8C…) in the header set-cookie field when it returns a response to the client. .

After receiving the Session ID from the server, the client saves the Session ID as a Cookie on the local PC.

For example, if I log in to a forum, browser F12 will see the cookies saved locally.

Problems arising

Because the server also needs to save this session information for comparison with those sent by the client, it is better if the number is small, but if the number is large, the server will need to save more content pages, which will be unbearable.

In addition, it will affect the scalability of the server. For example, the service consists of two machines in A cluster, and the session ID is saved on server A after I log in before. However, the next request will not work if it is sent to server B, because the server did not save it, so it will not be recognized.

There are questions like:

  • This does not apply to non-browser clients, mobile phones, etc., because sessions rely on cookies, and mobile phones often do not have cookies
  • Because session authentication is essentially based on cookies, users are vulnerable to cross-site request forgery attacks if cookies are intercepted. This method also fails if the browser disables cookies
  • This is especially not applicable in the system where the front and back end are separated. The back-end deployment is complex. The requests sent from the front end often pass through multiple middleware to the back end, and the session information in the cookie will be forwarded for many times
  • Session authentication cannot cross domains because it is based on cookies and cookies cannot cross domains. Therefore, single sign-on (SSO) is not applicable

Server: Alas! Damn sessionID, if only it could not be used o(╥﹏╥)o.

Token

Huh? In fact, the core of this matter is identity authentication, to find a way to solve the authentication, and do not need to save the server is not good:

  1. The client requests login using the username and password
  2. The server receives a request to verify the user name and password
  3. After successful authentication, the server issues a token and returns the token to the client
  4. After receiving the token, the client can store it, for example, in a cookie
  5. Each time a client requests resources from the server, it must carry a token signed by the server, which can be carried in a cookie or header
  6. The server receives the request and verifies the token in the request. If the verification succeeds, it returns the request data to the client

The point is that the server does not need to save tokens.

For example, when receiving the user name and password from the client for the first time, the server uses an encryption algorithm to generate a string as a token after the authentication succeeds. After receiving the token in the subsequent request, the server parses the token to obtain key information to determine the validity of the token.

Most of the systems I have come into contact with at present are based on token verification, because its advantages are more suitable for the current system application environment:

  • Stateless, easier to expand
  • More secure, preventing cross-site request forgery of CSRF
  • It facilitates cross-domain communication between multiple platforms
  • Can be standardized, such as JWT Json Based Web Token (JWT)