3 ms·
The idea of JWT is basically you give your user a "token" that can be used against many "services" while servers don't have to persist the state of that token,
by anon1252 8y ago
The idea of JWT is basically you give your user a "token" that can be used against many "services" while servers don't have to persist the state of that token, just be able to read the encrypted token, and trust the information in the token. The obvious issue is the server cannot easily revoke that token without blacklisting it, therefore persisting that token somewhere on a blacklist on the server. If you are going to make a lookup for a token in a blacklist you might as well look up for a session ID to being with.
- redbeard0x0a 8y agoTraversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs)
- anon1252 8y ago> Traversing a list of 100,000 users/sessions in a db to pull up the session is a different beast compared to traversing an in memory list of 10-100 revoked JTIs in redis. It is a lot less data to store and optimize (the full session vs. a small list of revoked JTIs) I don't see why one can't use redis to persist sessions at first place and why your list of revoked token would be limited to 100.
- luhn 8y agoIt's not explicitly limited to 100, but only a small portion of tokens will be revoked, so your revocation list will be small.
- finder83 8y agoIt does depend on how many users you have and your TTL for the JWT, but if you have a 10 minute time to live, you only need to store the revocations for 10 minutes in redis since otherwise the tokens themselves expire. (Just an example, sub 10 minutes with 24 hours or whatever)