0

I use Redis to track valid JWTs by saving the JTI (uuid-v4) mapped to the users id in Redis.

If the JTI can not be found in Redis or the user id in Redis does not match the user id in the JWT the access is denied.

If the JWT has expired (after 30 min) the client sends a token refresh request to get a new token which applies the same rules as before and also checks if the token is more than one month old, removes the old token from Redis, saves the new token to Redis and sends a new token or denies the request.

I also use this setup to invalidate all tokens for a user if the user's password has been changed.

Is there another reason beside the dependency on Redis and memory usage not to use Redis to keep track of valid JWTs ?

Improve this question
7
  • 3
    A big point of JWTs is that they are stateless so you don't have to check a database to see if the user's access credentials are still valid. If you want to keep them in a database so you can invalidate them, then why not just go back to good ol' fashion session IDs? Why bother with JWTs in the first place?
    – Conor Mancone
    Dec 7 '20 at 20:02
  • @ConorMancone I use the JWTs as a replacement for persistent cookies and CSRF protection and I do not want users to reauthenticate every time the session expires. Also, I don't see how JWTs without checking that they are still valid are a secure/good solution.
    – MADforFUNandHappy
    Dec 7 '20 at 20:17
  • persistent cookies and CSRF have nothing to do with JWTs. You must be storing your JWT somewhere in your app. You could store a session id in that location just the same as a JWT. As for checking the JWTs for validity, you of course have to check the expiration time of the JWTs, but otherwise the fact that you don't have to check if they have been invalidated is basically the entire advantage of JWTs. I mean, sure, you can always make a stateful system to allow you to invalidate JWTs, but at that point in time you are just doing sessions in a more complicated way.
    – Conor Mancone
    Dec 7 '20 at 20:22
  • 1
    Your missing my point: you can store JWTs in cookies and you can send session IDs in an authorization header. JWTs aren't a protection against CSRF because CSRF is a function of how you store your authorization token, and so can apply equally to JWTs as well as session tokens. The main advantage of JWTs is that they are intended to be stateless, but by introducing a redis cache you are making them stateful. So again, why use JWTs at all? Why not just use sessions which are designed for being stateful?
    – Conor Mancone
    Dec 7 '20 at 21:40
  • 2
    Then you now have your answer! Is there a good reason not to track them? Because then they are no longer stateless, which largely defeats the purpose of having them. Of course plenty of people end up having stateful JWTs anyway, so that's hardly the end of the world. Invalidating JWTs after a password reset isn't really very important, so if that is the only reason you are adding in a redis cache I would personally recommend just keeping the lifetime short. If you really want to keep the cache then go for it though - you get to pick your own cost/benefit balance.
    – Conor Mancone
    Dec 8 '20 at 0:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.