On the client side, unless you have a very secure method, such as the storage of private data provided by the operating system, then 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.
A simple way to solve this problem
1. When storing, store the token symmetrically and unlock it in time.
2. The request URL, timestamp and token are combined together, signed with salt, and the server verifies the validity.
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 algorithm. However, it is not difficult to say that it is difficult. After all, it is a way to prevent gentlemen and villains. In other words, if you open it, the encrypted storage of the client will not be stored in plain text. ...
Method 1 can't get the stored ciphertext. Method 2 doesn't know your signature algorithm and salt, so you can eat them together.
But if token is handcuffed, he can naturally implant a mobile phone, and then his mobile phone can also be used as you, so you are blind.
Therefore, it can provide a mechanism that allows users to actively terminate the mechanism similar to the previous token, and can remotely stop the loss when it is stolen.
How can a person who can't even protect his mobile phone talk about safety? ...
It is very dangerous to transmit token in plain text at the network layer, so it is recommended to use HTTPS and put token in the post body.