4 ms·

Sorry, I'm going to be a contrarian here. JWTs can be good. First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either loc

by ccleve 8y ago

Sorry, I'm going to be a contrarian here. JWTs can be good. First, cookies-vs-local storage is a non-issue here. If a JWT is small, it can be put in either location. The only real issue is, should session state be on the client or on the server? Suppose you have an app with large numbers of users, doing hundreds+ of queries per second across many boxes. If you put session state on the server, then you must either 1) have sticky sessions, which generate problems when a server goes down; 2) have a central session server, which generates scalability and reliability problems; 3) have a Redis-like distributed system, which either a) must do one or more server-to-server round trips on every client call to validate the session, or b) cache session information on a node. When latency matters, an extra server-to-server round trip is a non-starter. And if you do server-side caching, then cache invalidation and JWT invalidation present similar problems. ("There are only two hard things in Computer Science: cache invalidation and naming things."). Server-side sessions don't really buy you much. If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work. JWT is a good solution to the problem. You can store small amounts of session state on the client and simplify the whole system. You can avoid having to do lookups to determine state variables. (What database was the user connected to? Is he in mode A or mode B? What timezone? What language?) Put a short expiration on the token (a minute? five minutes?) and force the user to re-validate against some data store after that. The benefit is that you greatly reduce internal server traffic at the cost of not being able to invalidate a session within your short timeout interval. Depending on your app, letting someone remain an admin for an extra minute is not a big deal. And if it is a big deal, you can still handle it by sending a message to each node telling it to invalidate that particular user. A pain, yes, but the tradeoffs may be worth it.

CiPHPerCoder 8y ago
> If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work. They're built in with PHP and most Node.js frameworks I've ever worked with. I'm not sure about Python, RoR, etc. web frameworks but the engineering overhead for adopting server-side sessions should approximate 0, since they're usually the default.
- alliecat 8y ago
  Ruby dev here, Rails is pretty good at sessions. I hear the Python crowd have some great stuff too.
tschellenbach 8y ago
Also you're typically already looking up the user so you can just add a token_version property on the user and increment it when you want to expire tokens for that user. JWT problem solved without any additional work for the db.

by ccleve 8y ago

CiPHPerCoder 8y ago

> If you're using a system that has them built in, lovely, but if you're not, it's a lot of extra work. They're built in with PHP and most Node.js frameworks I've ever worked with. I'm not sure about Python, RoR, etc. web frameworks but the engineering overhead for adopting server-side sessions should approximate 0, since they're usually the default.

alliecat 8y ago
Ruby dev here, Rails is pretty good at sessions. I hear the Python crowd have some great stuff too.

tschellenbach 8y ago

Also you're typically already looking up the user so you can just add a token_version property on the user and increment it when you want to expire tokens for that user. JWT problem solved without any additional work for the db.