Storing the token does not actually store the login status, but the token for calling the interface. As long as the token exists and has not expired, it is considered to be still in the login state.
There is actually no so-called "status" in the login status. Because http itself is stateless. Therefore, every time the client initiates a request to the server, the server must authenticate.
First time: The user provides username and password authentication, and the server authenticates the user through "username + password". After passing, the server will generate an authentication ID. The server will save this authentication ID and respond to the client with the authentication ID. The client will also save this authentication ID.
The second to the nth time: The client uses the saved authentication identification to initiate a request to the server on behalf of the user, and the server authenticates the user through the "authentication identification".
As for whether the authentication identification is stored in the client's cookie or in local storage, and whether to use the session mechanism or a custom token mechanism. It's just a specific implementation plan.
If you are using a browser, usually cookie+session. If it is an interface, such as an app, a token mechanism is usually customized.
Why do you do this? Because every request requires users to enter their username and password, users will go crazy.
So the client agent (browser), replaces the user. The authentication ID replaces the username and password.
Various technical implementation solutions are nothing more than safety and efficiency considerations
Essentially, it is no different from the user entering their username and password every time
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Storing the token does not actually store the login status, but the token for calling the interface. As long as the token exists and has not expired, it is considered to be still in the login state.
Save in the server’s session
Token is used for user login check. It is just an ID, and the specific content is on the server side.
There is actually no so-called "status" in the login status. Because http itself is stateless. Therefore, every time the client initiates a request to the server, the server must authenticate.
First time: The user provides username and password authentication, and the server authenticates the user through "username + password". After passing, the server will generate an authentication ID. The server will save this authentication ID and respond to the client with the authentication ID. The client will also save this authentication ID.
The second to the nth time: The client uses the saved authentication identification to initiate a request to the server on behalf of the user, and the server authenticates the user through the "authentication identification".
As for whether the authentication identification is stored in the client's cookie or in local storage, and whether to use the session mechanism or a custom token mechanism. It's just a specific implementation plan.
If you are using a browser, usually cookie+session. If it is an interface, such as an app, a token mechanism is usually customized.
Why do you do this? Because every request requires users to enter their username and password, users will go crazy.
So the client agent (browser), replaces the user. The authentication ID replaces the username and password.
Various technical implementation solutions are nothing more than safety and efficiency considerations
Essentially, it is no different from the user entering their username and password every time