After reseaching the differences between OAuth and JWT, I decided to use JWT on my next project for simplicity and performance reasons.

From what I learned until now, and please correct me if I'm wrong, JWT is self contained data, hashed with a public key on the client. I then can check it against a secret key and verify its validity on my backend. Ok..

But there is one thing that I still can't quite understand: JWT token revoking. I saw many posts and topics about "How to revoke JWT" or whether it's "Possible or not to revoke JWT", "JWT Blacklisting", and even some posts saying there's no point in any of it.

I want to understand: Why would I want to revoke JWT? Would not revoking it be a security flaw? How?

  • 1
    You don't want to support a logout feature? Commented Jul 21, 2017 at 8:01
  • 1
    Long living tokens make our "sessions" more vulnerable too. If the token gets compromised, whoever stole the token is going to have plenty access to the user's resources for an undetermined lapse of time. In these cases, you will desire to have a way to expire tokens prematurely just for what CodesInChaos is suggesting: To be able to log out a "session" anytime from the only point under your control (backend)
    – Laiv
    Commented Jul 21, 2017 at 8:45

2 Answers 2


The default implementation of a JWT is stateless. That means you don't hold any information regarding the individual token in any form of storage (files, databases, memory, etc.). You're relying on the signature of the JWT to validate that you have issued this token.

This not more or less secure than a stateful token per se as far as protecting the token goes. It does however have security implications for a compromised token.

Since you have no way of knowing which individual token is due to not storing any information about them you cannot reject tokens which pass the basic signature validation. This means that if I somehow managed to acquire your token I will be able to pose as you until the token expires.

You can create a stateful JWT. Just store some data about it the token and in a database. Say a unique ID along with to whom it was issued. I've done a few different things over time with JWTs to keep them in good shape:

  • Store the API version which issued it
  • Store a password version of the user in it (meaning a password update revokes old tokens)
  • Store a unique ID to identify individual tokens

For the record, revoking a token typically means outright removing the token information from your storage or marking it as deleted; as such it is rejected when authorization is attempted.

For the record I'm not saying that you need to add state to the token so long as you are aware of the implications. Personally I would add some state, not for myself but for the users. Security concerns is typically at the bottom of their list until something tragic happens.

  • Storing the password version seems really strange. I like better the solution when after a password change a UserHasChangedPassword(UserId) event is dispatched which produces a command to InvalidateUsersTokens(UserId).
    – Andy
    Commented Jul 21, 2017 at 7:02
  • 1
    @DavidPacker I'm not opposed to that methodology, this was however the best way to deal with some specific requirements and underlying storage used at the time.
    – Robzor
    Commented Jul 21, 2017 at 7:38

Here are a reasons you would want to revoke JWT:

  • User wants to "log out". Should clear all sessions and revoke the JWT
  • You notice uncharacteristic/malicious activity coming from a certain user's JWT

Revoking is important because you need to be able to cancel access to your systems. If a malicious person got access to one of your legitimate user's JWT, and without the ability to revoke JWT, you would have to disable the user's access via access control which would affect the legitimate user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.