4 ms·

The server can invalidate the token at any time.

by cheez 7y ago

arethuza 7y ago
To do that you need to store some information about the token centrally so that any server receiving the token can check to see if it is valid or not - and if you are going to do that why not use an opaque random token and store all of the data that would have been in the JWT in the store?
- tehbeard 7y ago
  Storing a dozen bytes of 5,000 expired token ids until they expire vs several hundred bytes of 100,000 sessions. Granted, its use case leans towards big systems, or systems that cross boundaries between orgs.
- zxcmx 7y ago
  Not the OP, but I guess the TL;DR for me is that it's usually ok for sessions to be loosely consistent, and you can upgrade to "hard" consistency where you need to. Enforced session state consistency creates a hard runtime dependency on the backend service that provides that data and that service needs to scale to handle every single client request with low latency because the token to session state lookup dictates a floor on the response time of every other service you can possibly provide. It's not "wrong", of course lots of systems work like this, it has some advantages! It's just a tight runtime coupling that constrains how you can scale in some ways. The way I think about it is, if you have jwts you can always add additional "hard consistent" session state in the way you describe, but you're not forced to use it for everything. You have options, you can make tradeoffs. And in engineering, room to make tradeoffs is a great thing to have. As an example, with basic jwt sessions you can write say, a non-sensitive geodata lookup service for frontend (don't really care if user session is "valid" for an extra minute after "logout") in a lambda say, scale it to bejesus, but still be able to attribute requests to a user and do rate-limiting, and it has no availability dependencies on anything else. Ok sure though, maybe change profile info (a low volume request), you need to eat a hard invalidation lookup.
- cheez 7y ago
  Could you encrypt the JWT content with user-specific keys and cycle those keys in case of an issue?

The server can invalidate the token at any time.

by cheez 7y ago

The server can invalidate the token at any time.

To do that you need to store some information about the token centrally so that any server receiving the token can check to see if it is valid or not - and if you are going to do that why not use an opaque random token and store all of the data that would have been in the JWT in the store?

tehbeard 7y ago
Storing a dozen bytes of 5,000 expired token ids until they expire vs several hundred bytes of 100,000 sessions. Granted, its use case leans towards big systems, or systems that cross boundaries between orgs.
zxcmx 7y ago
Not the OP, but I guess the TL;DR for me is that it's usually ok for sessions to be loosely consistent, and you can upgrade to "hard" consistency where you need to. Enforced session state consistency creates a hard runtime dependency on the backend service that provides that data and that service needs to scale to handle every single client request with low latency because the token to session state lookup dictates a floor on the response time of every other service you can possibly provide. It's not "wrong", of course lots of systems work like this, it has some advantages! It's just a tight runtime coupling that constrains how you can scale in some ways. The way I think about it is, if you have jwts you can always add additional "hard consistent" session state in the way you describe, but you're not forced to use it for everything. You have options, you can make tradeoffs. And in engineering, room to make tradeoffs is a great thing to have. As an example, with basic jwt sessions you can write say, a non-sensitive geodata lookup service for frontend (don't really care if user session is "valid" for an extra minute after "logout") in a lambda say, scale it to bejesus, but still be able to attribute requests to a user and do rate-limiting, and it has no availability dependencies on anything else. Ok sure though, maybe change profile info (a low volume request), you need to eat a hard invalidation lookup.
cheez 7y ago
Could you encrypt the JWT content with user-specific keys and cycle those keys in case of an issue?