JD Interview: What are the differences between Cookie, Session and Token?

As one of the three giants of traditional e-commerce (the others are Alibaba and Pinduoduo), the difficulty of Dongzi's interview questions is also average. Generally speaking, it is not as difficult as the other two interviews, and of course the salary is not as high as the other two.

Among them, Pinduoduo's salary is the most outrageous, especially in the past few years. I heard that they poached developers from the same industry and offered them salaries that were two to three times their original salaries. It's really abnormal (but I like it).

Dongzi's interview questions are as follows:

picture

Most of the interview questions can be answered on my website (www.javacn.site), so I won’t go into details here. Today we will only talk about: What are the differences between Cookie, Session and Token?

1. What are the differences between Cookie, Session and Token?

Cookies, Sessions, and Tokens are usually technologies used to save user login information, but there are big differences between the three. Simply put, Cookies are suitable for simple state management, Sessions are suitable for scenarios where user sensitive information needs to be protected, and Tokens are suitable for state-independent authentication and authorization.

Analysis of Token state independence: In the traditional session-based authentication method, the server needs to save the user's session state in the backend and manage the session through the Session ID. The Token mechanism does not need to save any user status information on the server. When the login is successful, the server only needs to generate a unique Token value through a certain algorithm, and then send this Token to the client for storage (stored in localStorage or sessionStorage). Note that the server does not store this Token value at this time. The server only verifies but does not save this Token. This is called "state independence". This can reduce the burden of the server to store and manage the session state, so it is more suitable for large systems and distributed systems.

Specifically, the differences between Cookie, Session and Token are as follows:

1. The storage locations are different: Cookies are stored on the client side, that is, text files in the browser, and are passed to the server in the HTTP header for communication; Session is a server-side storage method, usually stored in the server's memory or database; Token is also stored on the client side, but is usually stored in an encrypted manner in the client's localStorage or sessionStorage.
2. Different data security: Cookies are stored on the client and may be stolen or tampered with, so the storage of sensitive information needs to be encrypted; Session is stored on the server and is associated between the client and the server through a Session ID to avoid direct exposure of sensitive data; Token is usually generated using an encryption algorithm, has a short validity period and is one-way irreversible, which can provide higher security.
3. Different cross-domain support: In order to prevent security incidents, Cookies do not support cross-domain transmission, that is, Cookies under different domain names cannot access each other; and the Session mechanism usually saves Session ID through Cookies, so Session ID does not support cross-domain by default; but Token can easily achieve cross-domain, because Token is stored in the client's localStorage or sent to the server as part of the request header, so the transmission of Token information of different domain names is usually not affected.
4. Different state management: Cookie is a mechanism for implementing state management by storing temporary data on the client side; Session is a way for the server side to record user status. The server will assign a unique Session ID to each session and associate it with the user status; Token is a mechanism for authentication and authorization, usually representing the user's identity information and permission information.

2.What is the relationship between Cookie and Session?

To be precise, the implementation of Cookie has nothing to do with Session, but the implementation of Session requires the help of Cookie.

The implementation process of the Session mechanism is as follows:

1. Session creation: Usually, when a user logs in successfully, the server will create a new session for the user. During the session creation process, the server will generate a unique identifier for the session, usually called a Session ID.
2. Session ID transmission: The server sends the generated Session ID to the client through a response, and uses the SetCookie command to save the user's Session ID in a cookie, usually a cookie named JSESSIONID.
3. Session data storage: On the server side, session data will be stored in a data structure that can be associated with the session ID (such as memory, database, or file storage, etc.). The common method is to use the session ID as a key and associate it with the corresponding session user identity data.
4. Session ID verification and retrieval: When a user sends a new request, the client will send the previously stored Session ID to the server in the request cookie or request header. The server will find the corresponding Session data based on the Session ID to obtain the user's status information.
5. Session data usage: After obtaining the Session data, the server can read, modify or delete the status information stored in it according to specific needs. The server can use Session to manage the user's login status, shopping cart content, user configuration, etc.
6. Session expiration and destruction: Session has an expiration date, which is usually set at a fixed time, or marked as expired when there is no user activity for a certain period of time. When the session expires, the server will destroy the corresponding session data and release memory or other resources.

So by default, the Session uses Cookies to complete the transmission of identity identification, so that the server can associate the Session ID with the saved session information to find a specific logged-in user. Therefore, by default, the Session mechanism relies on Cookies.

3. Can Session still be used after disabling Cookies?

From the above, we know that by default, the Session mechanism is implemented by relying on Cookies. So does it mean that after disabling Cookies, the Session mechanism will no longer be usable? Actually, it is not.

In addition to the default, we can use cookies to pass the Session ID, we can use some special means to pass the Session ID by ourselves, so as to get rid of the situation where the Session cannot be used after disabling cookies, such as the following two implementation methods:

1. URL Rewriting: You can append a Session ID parameter to the URL of each request. When the server receives a request, it parses the Session ID in the URL and associates it with the corresponding Session data. This method is suitable for situations where parameter passing in the address bar is not disabled.
2. Hidden form fields: Session ID can be passed to the server as a hidden form field. When the user submits the form, the Session ID will be sent to the server along with the form data, and the server will establish an association with the current session based on it.

The above methods can pass the Session ID to the server (although it is a bit troublesome). Then on the server, we can obtain and map the Session ID passed above. In this way, the work of passing and matching the logged-in user is manually completed, and the Session mechanism can continue to be used.

summary

Cookies, Sessions, and Tokens are usually used to save user login information, but there are big differences between the three: Cookies are suitable for simple state management, Sessions are suitable for scenarios where sensitive user information needs to be protected, and Tokens are suitable for state-independent authentication and authorization. By default, Sessions use the Cookie mechanism to pass Session IDs, but when Cookies are disabled, Session IDs can still be passed using special means, and the Session mechanism can still be used. Tokens do not save session information on the server side, so they are more suitable for large and distributed projects.