in the case of front-end and back-end separate interfaces, if you need something related to the user, you need it. If you don't then the end interface, how can you know who you are and whose data you can get
everyone can read it, and you don't have to use token. If you view it with different permissions, you must carry token.
token is equivalent to the unique identity of the user in the HTTP request, which can be understood as each person's ID number, and all the information of a specific person can be found according to the ID number. Therefore, in requests for passing token parameters, the system is generally required to determine the identity of the interface, using token to determine which user or client is accessing the service.
token is a string. Generally speaking, the string is obtained by the server from the local machine model, or the mac address or sessionid, is put into the server's session. In fact, token can be regarded as a seesionid.
cookie is carried by default for every request, but token does not need to be carried. Token can customize the request header and add it when sending the request.
therefore, it is clear that in some scenarios that need to verify user information, you need to bring token
access with token if you want to log in, and token also needs to log in to generate
. A very common scenario is login validity. Therefore, after the current end user logs in successfully, the backend will tell the front end that the login is successful and issue the token. After that, the foreground and backstage have to discuss where the expiration of token is realized.