What is the difference between Cookie, Session and Token

Cookies

1. What is a cookie? An
   HTTP cookie (also called a Web cookie or browser cookie) is a small piece of data that the server sends to the user's browser and saves it locally. It will be carried and sent when the browser initiates a request to the same server next time On the server, it is usually used to inform the server whether the two requests come from the same browser. For example, to keep the user's login status, Cookie makes it possible to record the stateless HTTP protocol and to stable state information.

2. The role of cookies

• Session state management (such as user login status, shopping cart, game score or other information that needs to be recorded)
• Personalized settings (such as user-defined settings, themes, etc.)
• Browser behavior tracking (such as tracking and analyzing user behavior, etc.)
  Cookies were once used to store client data, because there were no other suitable storage methods at that time, but now modern browsers begin to support a variety of storage methods. Cookies are gradually eliminated. After the server specifies a cookie, each browser request will carry cookie data, which will bring additional performance overhead (especially in a mobile environment). The new browser API has allowed developers to directly Data is stored locally, such as using web strorage API (local storage and session storage) or IndexedDB.

3. cookie version

• Netscape version of cookie : Netscape technical staff invented the cookie and formulated relevant rules and standards.
• RFC2109 version cookie : Netscape's competitors standardize cookies on the basis of Netscape version cookies.
• RFC2965 version cookie : defines an extended version of cookie, introducing Set-Cookie2 header and Cookie2 header.
• RFC6265 version cookie : The cookie standard of Netscape is regarded as the de facto standard in the industry, and the product after redefining the cookie standard.
• The current mainstream cookie version : The most widely used cookie standard is not any of the above, but the product of the expansion of the standard established by Netscape.

4. Cookie creation
   When the server receives an HTTP request, the server can add a Set-Cookie option in the response header. The browser usually saves the Cookie after receiving the response, and then requests the header through the Cookie in every request to the browser. The cookie information is sent to the server. In addition, the expiration time, domain, path, validity period, and applicable site of the cookie can all be determined according to requirements.
   A simple cookie might look like this: Set-Cookie:<cookie name>=<cookie value>
   

5. type of cookie

• Session Cookie : Session Cookie is the simplest Cookie, it will be deleted automatically after the browser is closed, which means it is only valid during the session. The session cookie does not need to specify the expiration time or validity period. It should be noted that some browsers provide a session resumption function. In this case, even if the browser is closed, the session cookie will be retained, as if the browser has never Close the same,
• Persistent Cookies : Unlike session-period cookies that become invalid after closing the browser, persistent cookies can specify a specific expiration time or validity period. When the cookie expiration time is set, the set date and time are only related to the client, not the server
• Third-party cookie : each cookie will have a domain associated with it. If the domain of the cookie is the same as the domain of the page, then we call this cookie a first-party cookie, and if the domain of the cookie is different from the domain of the page, it is called Third-party cookies. When a page contains pictures or resources stored on other domains, the first-party cookies will only be sent to the server that sets them. The third-party cookies sent through third-party components are mainly used for advertising and web tracking. You can see in this regard For the type of cookie used by Google, most browsers allow third-party cookies by default, but third-party cookies can be blocked through attachment components.
  6. Cookie attributes
  Secure and HttpOnly attributes : Cookies marked as Secure should only be sent to the server through requests encrypted by the HTTPS protocol. However, even if the Secure mark is set, sensitive information should not be transmitted through cookies, because cookies are inherently insecure, and the Secure mark cannot provide a real security guarantee. Starting with Chrome52 and Firefox52, insecure sites cannot use the Secure mark of Cookie. In order to avoid cross-domain scripting (XSS) attacks, cookies with the HttpOnly mark cannot be accessed through the Document.cookie API of JavaScript. They should be sent to the server. If the cookie containing the session information of the server does not want to be called by the client javascript script, Then the HttpOnly flag should be set.
  Scope attribute: The Domain and Path tags define the scope of the Cookie, that is, which URLs the Cookie should be sent to. The Domain tag specifies which hosts can accept cookies. If it is not specified, it defaults to the host of the current document (not including the subdomain name). If the Domain is specified, the subdomain name is generally included. For example, if you set Domain=mozilla.org, the cookie is also included in the subdomain name (such as developer.mozilla.org). The path identification specifies which paths under the host can accept cookies (the url path must exist in the request url). With the character %x2f ("/") as the path separator, the sub-path will also be matched.
  For example, if you set path=/docs, the following addresses will match:

/docs
/docs/web/
/docs/web/http

SameSite Cookies : Allow the server to request that a certain cookie will not be sent during a cross-site request, thereby preventing cross-site request forgery attacks. SameSite Cookies is a relatively new field that has been supported by all major browsers. For example: Set-Cookie:key=value;SameSite=Strict

SameSite can have the following three values:
None : The browser will continue to send cookies under the same site request and cross-site request, and it is not case sensitive.
Strict : The browser will only send cookies requested by the same site (that is, the current web page URL is exactly the same as the requested target URL). If the request comes from a URL different from the URL of the current location, the cookie marked with the Strict attribute is not included.
Lax : In the new version of the browser, as the default option, Same-site cookies will be reserved for some cross-site sub-requests, but will only be sent when the user navigates to the url from an external site, such as a link link.

session

1. Session synchronization issues

• session replication
• Client save session
• Fixed user access server: IP HASH, business data hash
• Shared storage

Token

• Support cross-domain
  1. Types of tokens
• access_token
• refresh_token