Token is a receipt, but it is much milder than a ticket. If you lose the ticket, you have to spend money to buy it again. If the token is lost, you can re-authenticate it. Therefore, the cost of token loss is tolerable-provided that you don't lose it too often, if you let users authenticate once every three or five times, it will lose the user experience. \x0d\\x0d\ On the client side, unless you have a very secure method, such as the storage of private data provided by the operating system, the token will definitely be leaked. For example, if I take your mobile phone and copy your token, I can log in as you elsewhere before the token expires. \x0d\ Simple method to solve this problem \x0d\ 1. When storing, store the token symmetrically and unlock it in time. \x0d\2。 Combining the request URL, timestamp and token, adding salt and signature, the server verifies the validity. \x0d\ The starting point of these two methods is that it is easier to steal your stored data, but it is more difficult to disassemble your program hack and your encryption and decryption and signature algorithms. However, it is not difficult to say that it is difficult. After all, it is a way to prevent gentlemen and villains. That is to say, if a client's encrypted storage is opened, it will not be stored as plain text? \x0d\ Method 1: It cannot obtain the stored ciphertext; Method 2: It doesn't know your signature algorithm and salt, so you can eat them together. \x0d\ But if token is handcuffed, he can naturally implant his mobile phone, and then his mobile phone can be used as you, so you are blind. \x0d\ can then provide users with an active expiration mechanism, similar to the previous token, which can stop loss remotely when stolen. \x0d\ How can a person who can't even protect his mobile phone talk about safety? \x0d\\x0d\ It will be very dangerous to transmit the token in clear text at the network level, so it is recommended to use HTTPS and put the token in postbody.