[spookthesunset]

I did... I made a decision tree. It's really that easy. The hard part is deciding what requests are sensitive and which aren't and that's a business decision not an engineering decision.

Adding redis or some crazy pub-sub crap to deal with logged out tokens.... that is truly making it far more complex. JWT is all about you deciding which pages truly need real-time "this token is invalid" and which don't.

Once you decide all requests need real-time you either are lying to yourself or JWT truly isn't the correct answer.

[treve]

> I did... I made a decision tree. It's really that easy

I think we are past an intellectually honest discussion. Disappointing. Good luck with everything.

[spookthesunset]

Good luck too. It really is easy though. That is the flowchart you need to use. Dunno what else to say.

[nichch]

You keep parroting "complexity", yet in your original argument you stated that for "sensitive" requests, you should just hit the backend anyway.

So that implies that you already have a database setup and you are already using it in your app. That means there is zero extra operational or deployment complexity (compared to implementing a completely new and different bloated system.)

As for development complexity?

  var isTokenValid = await redis.get(`k:${token}`);
  if(isTokenValid != null) return next();
  return res.status(401).send('Unauth.');

[spookthesunset]

So all that network latency and cache validation come for free? What if the system isn't in the same LAN and has a few hops... hops that may involve the speed of light over a few thousand miles and all it's slowness...

I don't think you've thought about the problem space enough.

[seanieb]

> I don't think you've thought about the problem space enough.

God grant me the self confidence of this fella.

I’ve been working as infosec engineer and been arguing with frontend engineers ( note its usually an individual) wanting to implement JWTs for years. Large companies with complex distributed systems, and the expertise to run them, however unless you’re doing some heavy API stuff or you’re Google scale it almost always is the wrong choice ( more often the request highlights an engineer who had almost exclusively been in the JS ecosystem and has very little backend experience).

[nichch]

I don't think you have thought about the problem space enough.

Nobody has disputed that JWT reduces network latency. My argument is that JWTs are unnecessary complexity for your app, overused, potentially dangerous [0] and for 99% of use cases: probably unneeded.

Let me demonstrate my claims.

Average TTFB (Time to first byte) on mobile is 2.594 seconds [1]. TTFB is the duration from the HTTP request to the first byte received from the server.

> a few thousand miles

Sure. Worst case scenario, right?

I set up a MongoDB Cluster on Mongo Atlas. I selected the AWS Region 'eu-west-1', which is housed in Ireland. I am from America, so I estimate this physical distance at 3,500 miles. A true worst case for any web app. I plugged in some example tokens and then wrote an application that pulls down 1,000 random tokens.

My average latency was 113 MS.

So a "worst case" database connection scenario is only 4.3% of the TTFB.

Do you use a client side render framework allowing you to defer or asynchronously make database requests? Well, considering fully loading a webpage on mobile takes 27.3 seconds [1], that database request is now 0.41% of the time it takes to fully load that page. Less than 1 percent.

So the "best case" JWTs offer is the TTFB is reduced by 4% or full page load time is reduced by 0.4%. Is that a good thing? Yes, of course. Is it worth the trade offs? No.

Let me reiterate the tradeoffs that I personally see.

- Complexity in development, deployment and operations. (This is less of an issue if you started with JWTs.)

- Every single request your app makes is now larger, either slightly or significantly. (Larger requests also take more time, I'd wager that the 113 MS difference is much smaller when comparing a request with a JWT payload)

- Potential security issues ([0], [2])

- Unable to revoke tokens on demand (There are ways to achieve this, but you're literally implementing session tokens at that point...)

Your whole argument implies that TTFB is the most important metric. I can't imagine the first thing that startups do is spend time, money, and effort on trying to reduce their TTFB by 100 ms. Also, reiterating the literal article you are commenting on, "Statistically, most of us are building applications that won’t make a Raspberry Pi break a sweat." I can't dictate what individuals do with their own web apps but considering my web app does 1MS lookups to Mongo (not even redis), I can't see a situation in which JWTs are worth it.

JWTs are hype tech, and people love to ride that hype train. However, when we write code I believe we should be thoughtful as to how we write code. Before I start on a project or add a new module or even pick a database I look at the outcomes. What will this code do for my application? What will this code do for my users?

My users might have to deal with a few milliseconds of latency. Your users may have to worry about theft or loss of their personal data [0][2][3].

[0] event-stream survivor here. The most popular JWT module on NPM right now with 6.3 million weekly downloads has 15 dependencies from over a dozen contributors. Even if JWT is a secure standard in itself, that is a large attack vector.

[1] https://backlinko.com/page-speed-stats

[2] https://insomniasec.com/blog/auth0-jwt-validation-bypass

[3] You yourself said that "unless you are a bank or something [...] can tollerate 5 minutes worth of somebody getting ahold of a token that was used for a logged out session". 5 minutes of someone accessing an account they should not have access to is a unacceptable and huge security hole.