Question posted in
The official documentation can be found here.

Redis – Can a JWT be stateful?

I have always opt for having jwt over session because of the less over head in the backend side (keeping in mind that it all depends on the use case) but the major issue I am having with it is the invalidation of the token, for an example : in case of the user being deactivated, the relevant jwt would still be valid until it gets expired. Is there anyway to overcome this issue in a cost effective manner ?

PS – however I saw the term " revoking JWT " in the cookbook section on the featherjs
framework. but its still looks like they are using redis as a lookup which in turns make it inherit drawback of using sessions.

Tags:

2

Answers


  1. 0

    Once a JWT is issued it is valid for as long as the exp claim value. You can’t revoke a JWT, it’s not how JWTs are meant to work.

    As you pointed, out there are ways of mimicking the behaviour of revocation, but you need two things for that:

    • you need to have a database with information about which tokens are revoked
    • you have to make sure that whenever you consume the token you check online with the database.

    There is no other way to do that.

    If you really have a need to revoke JWTs it means that you need sessions, and you shouldn’t be using JWTs for that. You can have a look at this article to learn why. If you decide to stick to JWTs, have a look at this best practices article I wrote to know what to watch for.

    Login or Signup to reply.
  2. 0

    It can! My understand is that JWT is just a "standard" on how tokens can be defined and created. It doesn’t "force" you to use it statefully or statelessly. This may looks weird because we only see developers and articles explaining how to use JWT statelessly, and unfortunately that’s a limited approach on how JWTs can help us. If you carefully read articles like this you can understand that they are more about being against stateless tokens in general rather than against stateful JWTs. It just happens that most people tend to implement JWTs as stateless tokens so it looks the only way to use it.

    Stateful non-JWT tokens are implemented with no standard in different frameworks. NodeJS’s Express, Java’s Apache Tomcat, Java’s Spring Boot, PHP’s Laravel, Python’s Django, each one has a different approach on stateful token formats and signature/encryption algorithms. The token’s content can vary from framework to framework so there is no standard, and that’s where JWT standarization help us.

    When you start defining your stateful JWT claims you may find some of the "default" ones to be useless, and there is nothing wrong with it. If you plan to store the stateful JWT inside a cookie, JWT’s "exp" claim (token expiration date) is useless because you can set the expiration inside cookie’s Expires attribute and well in the database, so you don’t need to set it in the JWT at all. Your application will always check for database validation before blindly accepting a valid signed JWT. You can find the "sub" field is not enough for you, and you need other fields such as "deviceId" and "userId". You are free to create as many claims as you want the way you want, using a JSON readable format with a default signature algorithm, that’s what it’s all about.

    Stateful tokens generation implementations on the frameworks I mentioned before are often signed by symmetric HMAC. When using JWT you can easily change between symmetric (HMAC) and assymetric (RSA). That’s a plus you get when using JWT for that.

    It’s a shame not many people discuss about this, stateful JWTs are possible and I personally think is a very nice way to use them.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search