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.
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.
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.
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.
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.
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.