If the backend is distributed (such as a cloud server), it is recommended to use the token verification method in oauth2.0. If it is just for development, you can use cookies.
oauth login process is as follows:

1. Create a new token table with fields token, user_id, login_at, expire_at

2. Users log in using their account and password

3. If the login is successful, a record will be inserted into the data table token, and all previous tokens of the user will be deleted or set to expire, and the token will be returned to the front end

4. Add header when using ajax on the front endAuthorization=token

5. The backend reads the Authorization in the request header and compares it with the database. If it exists and has not expired, it is considered a legitimate user, otherwise an error is returned

1 User login is generally cookie + session, even if the server is not the same. It would be better if one of them has a request forwarding function. Due to the restrictions of the same-origin policy, cookies cannot be used to access another domain name.

2 Generally, there will be a summary function on the front end to generate a summary of the data. Although it is posted with the data, the back end uses the same summary function to generate a summary of the posted data, and compares it with the summary of the posted data. If it is consistent This proves that the data has not been modified. But if the user knows what summary function you use, he or she can generate a summary of the data and post it. So in theory, it is impossible to judge, but in practice, ordinary users do not know this.

1. JWT, json web token.

2. How does the backend determine whether the data has been changed? What does it mean? Doesn’t the backend db store the data?

Back-end data verification, this is necessary to separate the front-end and back-end data security.
The usual way is to encrypt sign
What you need to use is key and secret
For example, the encryption method of Taobao API Taobao sign

key is the user ID, the name is who you are, and secret represents your key. The key is generated by the server and can only be used when encrypting the client. Sercet information cannot be included during data transmission.
After the client encrypts all request data according to specific rules, the backend obtains the submitted data and encrypts it in the same way, and then compares the sign parameters to see if they are consistent. If they are consistent, it means that the data has not been tampered with during the transmission process.
In addition, timeliness detection is also required, such as the timestamp parameter, which requires that the time error should not exceed 5 minutes before and after.
Another point is that if data is requested repeatedly, the backend will create a cache to store the sign after receiving the sign, and the expiration time is 5 minutes (and Corresponding to the above time), the same sign means that this request has been requested repeatedly and then rejected

Basically this is the process to ensure data security, timeliness, duplication prevention, etc.

sessionStorage or localStorage saves the special password generated by the background itself. Each request is carried through the head, and the data is verified to be legal through the background