Two schemes for login verification: token and cookie and comparison

cookie

HTTP is stateless, and each request must carry a cookie to help identify the user's identity; the
server can also set-cookie to the client, and the cookie size is limited to 4kb; cookies
have cross-domain restrictions by default, and are not shared and transmitted across domains, for example :

Modern browsers begin to prohibit third-party JS from setting cookies

Different from cross-domain restrictions, this refers to prohibiting third-party JS from setting cookies introduced by webpages. For example, if you have a website for comparing mobile phone performance, users can refer to the performance of mobile phones on your website. If you only visit your webpage, you are fine. Income, if you want to get more income, then you can implant some JD advertisements, and the advertisement content may be a picture, the code is as follows:

<img src="jd.com?info='华为手机'" >。

Although the js of the JD advertisement cannot access your cookie, because the cookie is not shared across domains, but you can get the content of the current web page (it seems to be related to the content of the mobile phone), once you have logged in to JD, then The request in the above code will carry your cookie information (jd will know who you are), and bring the content you are currently visiting along the way.

When you visit JD one day, you will find that JD will intelligently recommend which Huawei phone you want.

Therefore, a new SameSite attribute is added to the cookie to prevent CSRF attacks and user tracking .

SameSite has three values, among which Strict is the strictest, completely prohibiting third-party cookies, and will not send cookies under any circumstances when crossing sites. In other words, only when the URL of the current web page is consistent with the request target, the cookie will be brought.

Reference link: The difference between cookie and token

cookies and sessions

The cookie is on the client side, used for login verification, and stores user identifiers such as useId;
the session is on the server side, storing user detailed information, and corresponding to cookie information one by one;
cookie+session is a common login verification solution;

Why there is a session:

1. safety
2. Cookies are small in size and store limited information;
3. The cookie will be carried every time, if http carries less information, the transmission will be faster;

cookie vs token

• The cookie is an HTTP specification and will be passed automatically; while the token needs to be passed manually by the developer;
• The cookie will be stored by the browser by default; the token needs to be stored by itself (localstorage or sessionStorage);
• token has no cross-domain restrictions;

Cookies are the official login verification scheme, but despite the development of the Internet, cookies have exposed many limitations, so there is a token method initiated by the people, which is more flexible.

Implement token scheme jwt (json web token)

1. The front-end initiates login, and after the back-end verification succeeds, an encrypted token is returned;
2. The front end stores this token by itself (including user information, encrypted, asymmetric encryption);
3. When accessing the server interface in the future, this token will be carried as verification information;

Token vs cookie advantages and disadvantages and usage scenarios

Reference link: token vs cookie advantages and disadvantages and usage scenarios