Essentially, the front-end encrypts the data to reduce the readability, such as the user's sensitive data, for the purpose of privacy protection. If you pass the seesion_id, there is no need to encrypt it. As for the md5 method mentioned above, it is wrong (for passing seesion_id), because the seesion_id itself is used as a key, and md5 is a hash method (irreversible). If the backend wants to use it, it can be used directly. Come and use it, your layers of md5 are meaningless (if it is hijacked, just use it directly)

The token issue you mentioned lies in how the backend implements the authentication part, whether to restore the session to store information, or to use the token to verify the interface calling authority. It varies depending on how the backend is implemented.

Session is saved by a cookie placed in the browser, and relies on the browser's cookie expiration time to control the login retention time (client perspective).

For the rest of the content, please refer to this session cookie vs token

Encrypt a few more layers, an md5 is too simple.

Token, just have the MD5 encrypted date when logging in, then throw it into redis, and then block it in the interceptor to make a judgment

As long as no sensitive content (passwords, etc.) is stored, there is no problem for me. It is recommended to use the popular jwt. There are libraries implemented in various languages, and it is very convenient to use.

Session id is just a token, and md5 is redundant.

sessionid Isn’t it an encrypted plaintext token? There is no need to md5 it

It’s absolutely fine, use jwt. Pay attention to verifying the legality of the token.