3 ms·
JWT should not be looked at as a session replacement. For example, you cannot invalidate a JWT token before it's TTL. If you really wanted, you'd need to manage
by aleem 10y ago
JWT should not be looked at as a session replacement. For example, you cannot invalidate a JWT token before it's TTL. If you really wanted, you'd need to manage a blacklist of tokens on the server and compare every token against that list which would defeat the purpose of JWT's scalability benefits.
You can, however, come up with other strategies like switching up 100 permissions for 10 permission groups and similar ground-up designs which are JWT-friendly.
- 15155 10y ago> If you really wanted, you'd need to manage a blacklist of tokens on the server and compare every token against that list which would defeat the purpose of JWT's scalability benefits. The blacklist approach does presumably incur network latency, however, the amount of overhead/space for the blacklist is going to be substantially smaller than the total set of JWTs. Also: the blacklist only needs to be maintained until a blacklisted token naturally expires, further enabling performance. Any number of stores or structures would be suitable for the maintaining the blacklist: Memcached, Redis, even a bloom filter (especially if tokens aren't regularly blacklisted) will suffice. Granted, there are tradeoffs, and at this point, traditional sessions probably make more sense, but it s at least possible. It's much easier to scale recall from a (likely) small blacklist of token IDs + TTLs than all sessions, everywhere.