3 ms·

I love the idea of JWT but I don't understand how you would use them to store a lot of information, as the token it self would balloon in size. For example usin

I love the idea of JWT but I don't understand how you would use them to store a lot of information, as the token it self would balloon in size. For example using a JWT to authenticate an API request. The JWT would store a user ID and a list of permissions. What if a user has 100 permissions? The token is going to get huge....? Unless I'm completely misunderstanding how to use them.

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.

3 ms·

I love the idea of JWT but I don't understand how you would use them to store a lot of information, as the token it self would balloon in size. For example usin

by m4tthumphrey 10y ago

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.