From what I have read I see two approaches. You can use a per-user secret to sign a token. When the user wants to invalidate, change the per-user secret. Of course this will invalidate all issued tokens so no fine grain control.<p>Another approach is to use the jti field. Store all the jti's issued per user in a database. When a user wants to invalidate remove that jti. When receiving a token check if the jti is in the database for that user. Of course this is done after validating the integrity of the token and the database is kept up to date automatically removing jti’s that have expired. This offers fine grain control.<p>Do other approaches exist?
Can either of these be considered best practice?
I think that JWTs are not what you're looking for.<p>JWT's are meant to be stateless. Encrypt some claims, sign them, but no storage is necessary. A truly stateless system and the concept of revocation are mutually exclusive.<p>When you begin keeping track of nonces, jti's, or whatever, you've lost this "stateless" property.<p>In my opinion you should be using short lived JWTs and then don't worry about revocation.<p>About your specific questions. There are many pitfalls and operational issues associated with your solution.<p>- Changing a per user key is complicated. If it's a shared secret you have to securely redistribute it. If it's asymmetric key you need to republish the public keys, and have consumers poll to get the new key. Both of these kind of suck.<p>- The JTI thing is fine if you follow the spec and have a strongly random JTI.<p>Either way, you're trying to solve a problem that JWT is not meant to solve. Signing a new JWT and regenerating new JWTs is a cheap operation. Keep them short-lived, keep it simple.