Refer to the article: https://ninghao.net/blog/2834
HTTP is stateless, and each time a user enters a username and password and is authenticated, the next time the client sends a request, authentication is required.
The traditional authentication method session
Solutions: When a user requests login, it will be compared with the user name and password in the database. If it matches, a record will be generated in the server, namely session. The server will send the sessionID packet in this record to the client in the cookie, and the user can take this cookie when making a request to the server next time. The server will verify the information in the cookie to see if it can find the corresponding record on the server. If so, it indicates that the user has passed the authentication, and the server returns the data to the client.
Sessions may be stored in memory, on disk, or in a database. We might periodically clear expired sessions on the server.
Token-based authentication
Token-based authentication does not need to store user login records on the server. General process:
1. Log in to the client using the user name and password.
2. The server receives a request to verify the user name and password in the server database.
3. After the authentication succeeds, the server issues a token and sends the token to the client.
4. After receiving the Token, the client saves it in a Cookie or LocalStorage.
5. Each time the client requests resources from the server, it will bring the token issued by the server.
6. After receiving the request, the server verifies the token in the request. If the verification succeeds, it returns the requested data to the client.
Ways to implement tokens:
JWT: JSON Web Tokens
The JWT standard token has three parts
Header
payLoad
Signature (= signature)
The dots are separated and both are Base64 encoded, so the real token looks like this:
Header
It contains the encryption algorithm used.
Ex. :
JWT uses HS256. If the above content is encoded as a Base64URL, it looks like this:
Payload
Payload is the specific content of the token. Some of these fields are standard fields. You can also add other content as required.
Iss: Issuer.
Sub: Subject.
Aud: Audience.
Exp: expiration time.
NBF: Not before.
Iat: Issued at
Jit: JWT ID
Ex. :
Using base64Url encoding, it looks like this:
Signature
Header, payload, and secret are encrypted. As follows:
It will look something like this:
Tokens are finally generated on the server side:
The client receives the Token and stores it for the next time it sends a request back to the server. The server receives the Token, verifies it, and returns the desired resource to the client.
The difference between token and session:
Both tokens and sessions are for authentication purposes, with sessions generally translated as sessions, while tokens are more often translated as tokens.
The session server will keep a copy, probably in caches, files, and databases; Similarly, both sessions and tokens have expiration dates and need to be managed.
The issue of token and session is a game between time and space. Session is a space for time exchange, and token is a time for space exchange.
While it’s true that it’s all “client record, carried on every access”, tokens can easily be designed to be self-contained, that is, nothing needs to be logged on the back end, one stateless request at a time, one decryption validation at a time, and legal/illegal conclusions can be made on the spot based on the rules of the server side. All this is based on information that is self-contained, except for some logic solidified at both ends of the CS. This is true statelessness. A sessionID, on the other hand, is a random string that needs to go to the back end to check the validity of the ID. What if the server restarts and the session in memory is lost? What if the Redis server goes down?