Hacker News new | ask | show | jobs
by VWWHFSfQ 377 days ago
The major benefit of this approach is that you can avoid a database lookup when you have a valid JWT available. Only in cases where it's missing or expired would you need to hit the database for a refresh token.

This might not matter for trivial apps, but for very high-concurrency web apps this will matter a lot.
1 comments
0x457 377 days ago
Sure, but unless you're near Google scale, you probably shouldn't worry about that. IMO JWTs should not be used on public internet.
link
VWWHFSfQ 376 days ago
> unless you're near Google scale, you probably shouldn't worry about that

Even just a few million concurrent users on the website can cause a huge amount of load on the database just looking up sessions over and over again.

link
0x457 373 days ago
Yes, that's why long time ago we figured out how to store those in some extremely fast memory store like memcached or redis. I hope people that work at scale where it's not a viable option don't need to read such blog posts to set this up.

To store 1M sessions, let's say each is 2 KB, you going to need 2GB. Somewhere around 15K session look ups per second will saturate the server (+/- 5K ops/s depending on the CPU) . If you want more sessions - use more RAM, if you want more ops/s - use more servers (cache cluster).

Another reason to JWT - cross-region authentication (replicating giant session store across the globe isn't a viable option)

link