3 ms·
In my experience, the idea that JWT is stateless is wrong. When your client log-out you will need to keep the token in a blacklist and check all requests agains
by Znafon 7y ago
In my experience, the idea that JWT is stateless is wrong. When your client log-out you will need to keep the token in a blacklist and check all requests against it to make sure it is not reused until it expires.
Since you need to keep a list of invalid tokens, it's not easier to just use standard token. If what's you like in JWT is the ability to store a payload that your backend gets back, you can keep that in your store alongside the token and read it at the same time you check the token is valid.
IMO, JWT only makes sense when an other entity is doing the authentication of your clients.
- ravenstine 7y ago> When your client log-out you will need to keep the token in a blacklist and check all requests against it to make sure it is not reused until it expires. Sounds like a great way to DOS a server by running out its disk or memory space. (unless there's some sort of rate limiting in place)
- Znafon 7y agoHow does keeping a short token in redis or other would make the application easier to DOS than any other resource?
- ravenstine 7y agoBecause keeping a blacklist means keeping a list of all invalid tokens that haven't expired. If a user creates a crapload of sessions, you have to keep a running list of all the invalid tokens until they expire, which creates a few problems. You now have to have some mechanism to clear out tokens that have expired, which totally defeats one of the benefits of JWTs. And keeping a blacklist opens up the doors to someone slamming your /session endpoint, eventually running out your storage and/or memory because the blacklist will just keep growing. Sure, you can build in rate limiting, which you should have anyway. The reason I think this is still a problem is that a lot of amateurs are going to go straight for JWT and are too inexperienced or lazy to implement rate limiting. But why add all this complexity? Just have a whitelist, and you avoid these problems.
- Znafon 7y ago> You now have to have some mechanism to clear out tokens that have expired, which totally defeats one of the benefits of JWTs. I think we are making the same argument, JWTs are supposed to be stateless but can't as you need to be able to logout. > And keeping a blacklist opens up the doors to [...] running out your storage [...] because the blacklist will just keep growing. > But why add all this complexity? Just have a whitelist, and you avoid these problems. How does a whitelist helps you there?
- derptron 7y agoIf you require a blacklist, then you are doing JWT wrong. If you are using JWT to maintain client state, then you are doing it wrong.