[amarant]

Skill issue. I personally implemented the Minecraft Auth flow with JWT, and it handles ~250k req/s. It has the added benefit that already logged in users are unaffected if the Auth service goes down(Minecraft is a popular target for script kiddies and ddos attacks, so shit happens).

The entire argument the article does about invalidation confirms this: the bit about 5 year tokens. You do automatic token refreshes, which requires 5 extra lines of code on the client, and one network request every 30 minutes or so. Log out? Remove the token from the client, and let it expire in the next <30 minutes. Safe enough for most use cases.

It's fine to default to jwt, but yeah obviously you can screw it up if you implement it bad enough, and there are certain use cases where token expiry might not be safe enough (banking for example. But honestly with a short enough TTL it might be fine even there. You can totally do 5 minute tokens with automatic refresh gated behind user activity, if you need tighter security)

In the per-request cost table the author complains that signature validation is expensive, yet it's ~half the cost of a redis lookup according to the same table!

To me the entire article sounds like arguing that running shoes are bad because the author got a belly ache after eating one.

[nathanmills]

Can you explain how 30 minutes of unauthorized access is safe enough for most use cases? I feel like you glossed over that.

[minraws]

I think the perspective is most systems don't need validation based security, only access based security.

So it's fine for some services to serve requests after the access has been revoked for a few extra minutes or seconds.

For some it isn't. I have no say on the matter, I feel like security lax-ness makes sense for games, since jacking sessions with jwt is significantly less consequential and you have other sources to validate session health, such as route and ip address.

You can always revoke jwt if the ip address for which it was issue has changed or the route is different and so on and can be even more secure against forgery attacks.

Still not perfect and I find OP's take the it's good enough for banking to be sus.

But it's definitely not a scam, it's simple easy and trivial to use for a lot of low risk services.

You should build a map of low risk and high risk access and not use jwt for anything high risk, because jwts definitely provider better user experience for relatively less effort and resources and technical complexity needed.

[milch]

Apple App Store Connect has this issue for example. If you remove or downgrade someone from the store they retain access for however long... and they keep the ability to do destructive actions like remove or change the permissions of other users, at least they used to until a year or so ago when I last checked. They closed my security report as "by design" btw.

[minraws]

Yeah had a similar experience with a Youtube dashboard auth thing, folks in big tech don't care well either does my manager, it doesn't add to my KPIs and making things secure by making customer experience worse is just a product killer apparently and gets shot down real quick.

Honestly all this just makes me feel tired, like real tired, I honestly wished Mythos would set the software world on fire, some folks and companies deserve to burn.

But then I saw it's output and well.. I have KPIs to hit and a LLM slot machine lever to pull.

[tjansen]

You can use a more nuanced approach.

What I did in the last systems I created:

1. The JWT expiration depends on the user. Admins get only 1 minute or so, but regular users 1 hour. If I had an SaaS for enterprise customers, I would use very short expiration times for paying enterprise users, but long for non-paying users.

2. When 95% of all requests are reads, and it's not sensitive data, only validate the JWT. For dangerous operations, always require validation of the user status.

3. I prefer to let the server control the JWT lifetime. So the server can respond to any request with a 'token too old' error, and the client knows it must renew it and retry. That allows you to configure the expiration date of the token depending on the operation and how critical it is.

[amarant]

It's not 30 minutes of unauthorised access, it's 30 a minute window where you have some extra attack surface. It's safe enough because exploiting that small attack surface within the timelimit is sufficiently hard that it can be considered safe.

Of course the only completely hack-proof device is a brick.