I also come here in search of a solution, but after reading a lot, I came to several conclusions or said possible situations.
Edit Note: - Never save any potential information in a token, since reading data in a token does not require a secret key. The secret key is intended only to verify the signature of the Base64 token. To verify this, go to http://jwt.io and insert your token. I added this point because somewhere I saw a developer adding a username and password to a token. Please do not do such things.
1.) An account login event is triggered by a client if he wants to log out before the token expires. Solution: - Remove the token from anywhere on the client side. It can be stored in the DOM or JavaScript Variable, or in the HTML key store, or in the session store or cookie store. Wherever we can save a value in a browser, we also have rights to delete values. As soon as the token is removed from any corner of this world, the user logs out.
Caution 1 in the solution above
What to do if a user logs out in an emergency, for example, someone could unlock a token. How to destroy a token?
The answer is the same as if our secret key for JWT is canceled. We will quickly change the secret key and regenerate tokens for registered users. But in the case of users, what should we change? User ID (I will say no). We must add an account blocking mechanism similar to the mechanism in debit / credit cards, where the card is locked for 24 hours. But in our case, we should have a finite account blocking period slightly longer than the token expiration time.
2.) Tokens are just like rockets, after we are fired we cannot ask them to close. I’m talking about the ideal case if you store the link of the fired token in the database, which makes no sense to use JWT. We can generate a token using any hash generation method.
3.) Set the expiration time. Update, not allowing the user to notice this, a little before the expiration of the previous token. The time can be about 20 seconds. However, you need to consider providing a reservation 1, since anyone with a genuine token can request a fresh token.
4.) We can also add the IP address of the field to the token and check whether the current IP address of the users matches the one used during login or not. It prevents remote hackers.
5.) Add a clearly visible exit button to your user interface to prevent naive users and direct users to exit the application each time they are executed with your application.
6.) Add the client type to the metaphor of your token. For mobile applications, check the HMAC or IMEI codes for the IP address, as mobile applications require a session to continue, since no one wants his or her users to leave their mobile applications. However, a compromise may compromise the IMEI and the HMAC address. But accidental use between HMAC, IMEI, or any other available string can add a bit more security.
7.) I will add more if I find out more of these.
Invalid JSON Web Tokens This thread also has a lot of good source data. As mentioned in the comment on the question.