The downside I see in this approach is that you have to keep track of the incrementing number (or use a timestamp-based value), which means updating the database for every JWT created.
Another approach for revoking a JWT is to store the timestamp when the user ID was last revoked, then look at the "iat" field in the JWT. If a revocation date is found for the user, only tokens issued after that date are valid.
Having a separate global timestamp is also good for mass revocation (say in the case where your signing key is compromised).
The approach with storing the timestamp of the revocation work really well as long as you only have one JWT for a user/application. However, if for the specified account there are multiple JWTs (for example one used by the user and one by some automated tool), you will revoke both. There are workaround though, I believe, so I still consider your idea to be good :)
Thanks for the suggestion.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The downside I see in this approach is that you have to keep track of the incrementing number (or use a timestamp-based value), which means updating the database for every JWT created.
Another approach for revoking a JWT is to store the timestamp when the user ID was last revoked, then look at the "iat" field in the JWT. If a revocation date is found for the user, only tokens issued after that date are valid.
Having a separate global timestamp is also good for mass revocation (say in the case where your signing key is compromised).
The approach with storing the timestamp of the revocation work really well as long as you only have one JWT for a user/application. However, if for the specified account there are multiple JWTs (for example one used by the user and one by some automated tool), you will revoke both. There are workaround though, I believe, so I still consider your idea to be good :)
Thanks for the suggestion.