The duration for which you should save banned JWT tokens in Redis depends on the specific use case and the security requirements of your application.
In general, a token should be banned for a longer period of time if the reason for the ban is a serious security violation (such as a brute-force attack). The duration for the ban can be shorter if the reason for the ban is something less serious (such as a temporary lockout due to too many failed login attempts).
In terms of specific duration, it's recommended to have a short time-out period of 15 minutes to 1 hour for temporary lockouts, and a longer time-out period of 24 hours to 1 week for serious security violations.
It's also important to consider that storing too many banned tokens in Redis can consume a lot of memory, so you should periodically remove expired tokens from the set or hashmap.
TLDR: If you want the capability to revoke the token at some point, yes, store it in something fast like Redis.
One of the well documented drawbacks of using JWT is that there's no simple way to revoke a token if for example a user needs to be logged out or the token has been compromised. Revoking a token would mean to look it up in some storage and then deciding what to do next. Since one of the points of JWT is to avoid round trips to the db, a good compromise would be to store it in something less taxing than an rdbms. That's a perfect job for Redis.
As suggested in the comments a good approach is to make the list a blacklist (i.e. a list of invalidated tokens). Upon each request you look up the list to ensure the token is not present in it. You can further improve on memory space and performance during the lookup step by using a probabilistic algorithm to store the token. A simple approach is to have layered lookups. For instance, you could have a small in-app store that only tracks the first few (e.g 1 to 4) bytes of your blacklisted tokens. Then the redis cache would track a slightly more complete version of the same tokens (e.g. first 2 to 8 bytes). You can then store a full version of the blacklisted tokens using a more persistent solution (filesystem, rdbms, etc). This is an optimistic lookup strategy that will quickly confirm that a token is absent from the blacklist (which would be the more common case). If a token being looked up happens to match an item in the in-app blacklist (because its first few bytes match), then move on to an extra lookup on the redis store, then the persistent store if need be. Some (or all) of the stores may be implemented as tries or hash tables. Another efficient and relatively simple to implement data structure to consider is something called a Bloom filter.
Obviously, you'd have to adapt the above approach if you routinely blacklist millions of long-lasting tokens (which may also indicate that you have a different problem).
eduaravila
commented
1 year ago
The duration for which you should save banned JWT tokens in Redis depends on the specific use case and the security requirements of your application.
In general, a token should be banned for a longer period of time if the reason for the ban is a serious security violation (such as a brute-force attack). The duration for the ban can be shorter if the reason for the ban is something less serious (such as a temporary lockout due to too many failed login attempts).
In terms of specific duration, it's recommended to have a short time-out period of 15 minutes to 1 hour for temporary lockouts, and a longer time-out period of 24 hours to 1 week for serious security violations.
It's also important to consider that storing too many banned tokens in Redis can consume a lot of memory, so you should periodically remove expired tokens from the set or hashmap.
TLDR: If you want the capability to revoke the token at some point, yes, store it in something fast like Redis.
One of the well documented drawbacks of using JWT is that there's no simple way to revoke a token if for example a user needs to be logged out or the token has been compromised. Revoking a token would mean to look it up in some storage and then deciding what to do next. Since one of the points of JWT is to avoid round trips to the db, a good compromise would be to store it in something less taxing than an rdbms. That's a perfect job for Redis.
As suggested in the comments a good approach is to make the list a blacklist (i.e. a list of invalidated tokens). Upon each request you look up the list to ensure the token is not present in it. You can further improve on memory space and performance during the lookup step by using a probabilistic algorithm to store the token. A simple approach is to have layered lookups. For instance, you could have a small in-app store that only tracks the first few (e.g 1 to 4) bytes of your blacklisted tokens. Then the redis cache would track a slightly more complete version of the same tokens (e.g. first 2 to 8 bytes). You can then store a full version of the blacklisted tokens using a more persistent solution (filesystem, rdbms, etc). This is an optimistic lookup strategy that will quickly confirm that a token is absent from the blacklist (which would be the more common case). If a token being looked up happens to match an item in the in-app blacklist (because its first few bytes match), then move on to an extra lookup on the redis store, then the persistent store if need be. Some (or all) of the stores may be implemented as tries or hash tables. Another efficient and relatively simple to implement data structure to consider is something called a Bloom filter.
Obviously, you'd have to adapt the above approach if you routinely blacklist millions of long-lasting tokens (which may also indicate that you have a different problem).