1. Why do you need these three things?

HTTP is a stateless protocol, so each request is completely independent, and the server cannot confirm the identity of the current visitor or tell whether the sender of the previous request is the same person as the one who sent it this time.

In order to maintain the state of the client and server, these three things are generated

2, cookie,

Cookie stored on the client: A cookie is a small piece of data sent by the server to the user’s browser and stored locally. It will be carried and sent to the server the next time the browser makes a request to the same server.

Cookies are not cross-domain: each cookie is bound to a single domain name and cannot be used in other domains. Sharing between the first and second domains is allowed (depending on the domain).

3, the session

Session is another mechanism for recording the session state between the server and client

Sessions are cookie-based. The session is stored on the server, and the session ID is stored in the cookie on the client

3.1 Session Authentication Process

  • When a user requests the server for the first time, the server creates a Session based on the information submitted by the user
  • When the request returns, the unique identifier SessionID of this Session is returned to the browser
  • After receiving the SessionID returned by the server, the browser stores the information in a Cookie, and the Cookie records the domain name to which the SessionID belongs
  • When the user accesses the server for the second time, the request will automatically determine whether there is Cookie information in the domain name. If there is Cookie information, the server will automatically send Cookie information to the server. The server will obtain the SessionID from the Cookie. If the Session id is not found, the user has not logged in or the login is invalid. If the Session id is found, the user has logged in and you can perform the following operations.

Session and cookie are bound using the sessionID

4, Token

4.1 the Access Token

  1. Resource credentials required to access resource interfaces (apis)

  2. Simple token components: UID (the unique identity of the user), Time (the timestamp of the current time), sign (the signature, the first few bits of the token compressed into a certain length of hexadecimal string by the hash algorithm)

  3. Features:

    1. The server is stateless and scalable
    2. Support for mobile devices
    3. security
    4. Support for cross-program calls

  4. The authentication process for token:

  • The client requests the login using the user name and password

  • The server receives a request to authenticate the user name and password

  • After the authentication succeeds, the server issues a token and sends the token to the client

  • After receiving the token, the client will store it, such as in a cookie or localStorage

  • Each time a client requests resources from a server, it must carry a token issued by the server

  • The server receives the request, verifies the token in the client request, and returns the requested data to the client if the authentication is successful

  • Each request needs to carry the token, which needs to be placed in the HTTP Header

  • Token – based user authentication is a stateless authentication mode on the server. The server does not need to store token data.

  • Exchange the computing time of resolving tokens for session storage space, so as to reduce the pressure on the server and reduce the frequent query of the database

  • The token is completely managed by the application, so it can avoid the same origin policy

reference

Juejin. Cn/post / 684490…