34 ms·

The author says one of the selling points of JWT is scale, and points out many will not need to concern themselves with scale and to stick with simple solutions

The author says one of the selling points of JWT is scale, and points out many will not need to concern themselves with scale and to stick with simple solutions. But I am curious to know if any on HN is using session cookies at scale and how they solve the scalability issues of session cookies alluded to in the article?

nkozyra 5y ago
I think the whole "sessions don't scale" predates an era of cheap, shardable/distributable and performant options from NoSQL to RDBMS. It used to be a serious bottleneck for even smaller sites. But they also used to stick them in stodgy, table-locking storage engines in the same database as the rest of their application. Times have changed and I really believe you can manage cookies<->sessions without too much overhead. And if you're willing to let a JWT have a 5-minute max life, you could similarly cache your session responses for 5 minutes. Like all things, there comes a tipping point eventually. But it's not as early or as drastic as it once was.
echelon 5y ago
I've been heavily involved in an active-active session service that handles 100kqps+. It's not that hard to achieve with Redis. If you model your sessions as an acyclical state machine, you can quickly consolidate a single view of all sessions globally. Beyond this, it's valuable to be able to scope sessions, invalidate subsets of sessions, create delegate sessions, provide an audit trail for internal support staff using session impersonation, etc. JWTs can't give you a lot of the rich security behaviors that real sessions can, such as asking a user to use 2FA for editing sensitive data if they haven't provided that information in the last 15 minutes. Or estimate user idle time.
- jruthers 5y ago
  Would you be able to expand on scoped sessions, invalidated subsets, delegated sessions? Our roadmap has a big emphasis on improved session management and these are ideas we haven't considered and I'm keen to understand more.
  - echelon 5y ago
    These aren't industry standard terms. You might want to invalidate sessions from a particular device, IP, or time period. Or, if you detect a user is compromised, terminate all sessions on their behalf. You might want API and web sessions to have different properties, such as duration. Or limit access to certain endpoints based on device type. You might have a mechanism to turn one session type into another so that your app can open a browser and have the user already logged in. If your model has a superuser that has oversight into a lot of account-like views, you might want the ability to constrain it to a subset of permissions while handing it off to something else, especially if those sessions are longer lived. Or give it a subordinate view. You might want to assign confidence intervals to sessions based on heuristics and ask for a second factor for operations that require a given score. There's a lot you can do.
    - jruthers 5y ago
      Thank you, @echelon
- Wintereise 5y ago
  > such as asking a user to use 2FA for editing sensitive data if they haven't provided that information in the last 15 minutes Can't you just use the iat claim to check for issuance time for this one?
fma 5y ago
If you're looking for personal experience, I don't have it...But author does say "...but it’s common for sites to use systems like Redis and Memcached, which works for tiny sites, but still works at massive scales." ...which would be my first WAG if I had to design it for scale. Sites were at scale before JWT conjured up.
Lazare 5y ago
A surprisingly small number of dollars per month will give you a Redis instance that will solve your sessions needs for a truly absurd scale. And Redis scales horizontally pretty well too. (I say Redis, but there's many equivalent tools that'll work just as well.) Scale is relative, but...let's put it this way. If you're at the sort of scale where you might struggle to trivially use sessions at scale: 1. You'll know. If you're not sure you're at that scale, you definitely aren't. 2. You shouldn't be taking advice from Hacker News; go ask the large team of experts you've already accumulated about what works best for you. If you don't HAVE a large team of experts on staff already about operating at your massive, massive scale, then see point 1: You're not at that scale.

nkozyra 5y ago

I think the whole "sessions don't scale" predates an era of cheap, shardable/distributable and performant options from NoSQL to RDBMS. It used to be a serious bottleneck for even smaller sites. But they also used to stick them in stodgy, table-locking storage engines in the same database as the rest of their application. Times have changed and I really believe you can manage cookies<->sessions without too much overhead. And if you're willing to let a JWT have a 5-minute max life, you could similarly cache your session responses for 5 minutes. Like all things, there comes a tipping point eventually. But it's not as early or as drastic as it once was.

echelon 5y ago

I've been heavily involved in an active-active session service that handles 100kqps+. It's not that hard to achieve with Redis. If you model your sessions as an acyclical state machine, you can quickly consolidate a single view of all sessions globally. Beyond this, it's valuable to be able to scope sessions, invalidate subsets of sessions, create delegate sessions, provide an audit trail for internal support staff using session impersonation, etc. JWTs can't give you a lot of the rich security behaviors that real sessions can, such as asking a user to use 2FA for editing sensitive data if they haven't provided that information in the last 15 minutes. Or estimate user idle time.

jruthers 5y ago
Would you be able to expand on scoped sessions, invalidated subsets, delegated sessions? Our roadmap has a big emphasis on improved session management and these are ideas we haven't considered and I'm keen to understand more.
- echelon 5y ago
  These aren't industry standard terms. You might want to invalidate sessions from a particular device, IP, or time period. Or, if you detect a user is compromised, terminate all sessions on their behalf. You might want API and web sessions to have different properties, such as duration. Or limit access to certain endpoints based on device type. You might have a mechanism to turn one session type into another so that your app can open a browser and have the user already logged in. If your model has a superuser that has oversight into a lot of account-like views, you might want the ability to constrain it to a subset of permissions while handing it off to something else, especially if those sessions are longer lived. Or give it a subordinate view. You might want to assign confidence intervals to sessions based on heuristics and ask for a second factor for operations that require a given score. There's a lot you can do.
  - jruthers 5y ago
    Thank you, @echelon
Wintereise 5y ago
> such as asking a user to use 2FA for editing sensitive data if they haven't provided that information in the last 15 minutes Can't you just use the iat claim to check for issuance time for this one?

fma 5y ago

If you're looking for personal experience, I don't have it...But author does say "...but it’s common for sites to use systems like Redis and Memcached, which works for tiny sites, but still works at massive scales." ...which would be my first WAG if I had to design it for scale. Sites were at scale before JWT conjured up.

Lazare 5y ago

A surprisingly small number of dollars per month will give you a Redis instance that will solve your sessions needs for a truly absurd scale. And Redis scales horizontally pretty well too. (I say Redis, but there's many equivalent tools that'll work just as well.) Scale is relative, but...let's put it this way. If you're at the sort of scale where you might struggle to trivially use sessions at scale: 1. You'll know. If you're not sure you're at that scale, you definitely aren't. 2. You shouldn't be taking advice from Hacker News; go ask the large team of experts you've already accumulated about what works best for you. If you don't HAVE a large team of experts on staff already about operating at your massive, massive scale, then see point 1: You're not at that scale.