Change from blacklisting tokens to whitelisting them

[joaquinwojcik]

I propose switching from a blacklist approach to a whitelist approach for token management.
Instead of storing a large list of invalidated tokens, it will only keep track of valid tokens in a whitelist, removing them upon logout or revocation.

This significantly improves performance and resource usage, as the whitelist remains relatively small.
It also offers more control and transparency: any token not on the whitelist is automatically invalid, simplifying checks for token validity and ensuring clean, efficient handling of active sessions.

[mfn]

My IMHO is: this does not belong into this library.

Reasons:

• it's by far not an established practice
  Whereas using a deny list is (major players like python, ruby et al provide this out of the box).
• JWT are meant to be stateless
  With your proposal you could as well store the token on a users auth table and require it to match on every request, almost defying the primary use of JWT (though industry often well does it anyway)
• having a deny list is solution for another problem
  namely revoking still valid JWTs

The correct solution is to have short lived JWT and build that logic into your refresh flow whether you want to re-issue a token for a user or not.

[Messhias]

I don't think this belong here and also seems to be a breaking change

[specialtactics]

I'm sorry, but this is a terrible idea for so many reasons. I also don't really get why you have so many blacklisted tokens, perhaps that's a problem with your application/session design, you can explain your auth architecture and gets ideas - I think that would be a better approach.

Most applications, especially large scale, will have far more active tokens than blacklisted ones, there's obvious problems of scale storing so many JWTs, and the risks of losing such volatile storage (which is typically redis or equivalent, which is not 100% reliable).