How to revoke a JWT token | The JWT lifetime, blacklist and not-before policy

Support my work / pawelspychalski
One of the popular questions about JWT is how to revoke a JWT token. The thing is, you can't revoke a single token. You can build a blacklist of all the tokens you want to invalidate, but it's not the way! Just keep the lifespan on the JWT token (exp claim) short and disable the user if required.
What are JWT tokens? Modern authentication and authorization for microservices • What is JWT? The JSON ...
0:00 How to revoke a JWT token
0:43 A token blacklist concept
1:03 So, how to secure your app? Keep the lifetime of the JWT short
3:00 Key change and not-before policy
4:12 What have we learned today?
4:50 Outro
#quadmeup #jwt #programming
www.keycloak.org/docs/latest/...
If you want to support me:
✅ Patreon / pawelspychalski
✅ Banggood affiliate bit.ly/2P8oAxr
✅ Paypal paypal.me/pawelspychalski
▶ Discord server quadmeup.com/discord
▶ My website quadmeup.com/

[@PSAfterHours]

What are JWT tokens? Modern authentication and authorization for microservices th-cam.com/video/9nBu5qtVxMM/w-d-xo.html

[@TechnicallyTom]

I think there is a better way to revoke a JWT token than using a blacklist. If you change the secret stored on the server it makes all the tokens not valid. The way to handle revoking for only one user is to store part of the secret where you normally would store the secret and part on the user record. This prevents leaking the entire secret but allows the user part of the secret to be changed. The user secret can just be a randomly generated string that changes whenever a user changes their password. Another use case would be a token being used for forgotten passwords where you would change the user stored reset secret when the token has been used successfully. It also adds some additional security since every user has a unique secret for their token.

[@PSAfterHours]

Yeah, that's what not-before policy is used for. However, it i validates all token. Not only some of them

[@TechnicallyTom]

@@PSAfterHours By storing part of the secret on the uaer though, you can invalidate just one token.

[@PSAfterHours]

Hmmm, that's an interesting thought. I will have to investigate this option. Thanks for the hint

[@lidavid7809]

​@@TechnicallyTom Hi there, not sure how is that possible to get the part of user stored secret, if u let client to reset password from unique route. If I understand correctly u make a jwt secret out of user secret and secret in env?

[@TechnicallyTom]

@@lidavid7809 Yes. Secret is partially stored in env and partially stored on user. If you reset the secret on the user, the token is no longer valid. You need to fetch the user first before authorization.

[@sadeghhosseini6381]

We can have a version field in each tonken's payload, which is a number. We also store each version for each user to redis. On each request we compare the version in token's payload with the corresponding version in the redis, if not equal it means that the token has been invalidated hence the user is forced to refresh their token, then for invalidating a token we just have to increase the version in redis for a specific user.

[@FPVUniversity]

Well, the thing is this is not how JWT is supposed to work. The whole idea is to have a distributed system when JWT can be issues by a system you trust, not the system you control

[@bogdan.shahnitsky]

@PSAfterHours, You recommend to keep the lifetime of a Refresh Token under 20 minutes, but doesn't it mean that if user (for example) leaves our website for more than 20 minutes (not even mentioning going to sleep), he will be forced to log in again on the next visit?

[@moveonvillain1080]

Help me understand a bit more. Do you want to say that the user will have to "Sign In" every 20mins regardless of if the user is active or not active?

[@opticalmouse2]

The short version is to just use sessions.
What a shitshow with JWT and loging out!

[@PSAfterHours]

No, sessions are not the answer because session does not work with external identity providers. And logout mean usually that user logged out, not was forcefully logged out by admin.

[@opticalmouse2]

Like I said: What a shitshow with JWT and logging out!

[@opticalmouse2]

@@PSAfterHours "And logout mean usually that user logged out, not was forcefully logged out by admin."
You are right.