I think you are overlooking the main benefit of JWT - is to allow authentication by a trusted third party, thus enabling single sign on, eliminating the need for password storage and management, login forms, etcetera.
And once you’re doing that, it’s a small step to say:
“even if my users want to signup/login via username and password, I’d rather not manage that myself. I’d rather use a 3rd party system to store the passwords, implement MFA and password recovery and signup/login forms and whatnot, and just trust the id tokens from that system.”
Auth0, Keycloak, FusionAuth, etc. And again you’ll be dealing with OIDC and JWTs.
If you want to manage your own usernames, passwords, signup/login pages, password reset flows, MFA flows, etc., then yeah, I’d go with traditional sessions stored in a db/cache that you manage, and auth tokens are just session ids. But if you want to outsource all of that, plus support SSO, then the id token you deal with will not be traditional session tokens, they’ll most likely be JWTs issued by someone else, where you just verify the signature.
For example, if you don‘t trust the client you also cannot trust the logout button or know that the login credentials are not compromised.
So you would need a scenario where you get a token (let‘s say valid for an hour) and you use it on a computer that you trust and then someone can copy the token but afterwards you somehow trust the device again.
What am I missing?
Additionally most people never actively log out (especially on personal devices which are like 99%) so it’s practical to push a small list of invalidated and not yet expired tokens to all service caches in the rare case someone actually presses that logout button. Certainly much cheaper than checking them on each request or updating a cache of all sessions.
Wrong. You need to be able to invalidate tokens to other devices. (Lost device / revoked access use-case)
If you want to logout everywhere that‘s extremely rare and as I said such a table to capture this information would be tiny.
Additionally these tokens are short-lived. So even without token invalidation, the „logout everywhere“ can just invalidate the refresh tokens and all device are logged out within one hour.
I had (fully encrypted) devices stolen, of course, and I did revoke keys and changed passwords (just in case). But I never managed to do this within one hour and there was never a risk of anyone unlocking the device anyway.
Really not seeing the problem. In most non trivial apps authentication infrastructure is it’s own service anyway, so hitting auth0 on each call in practice works very similarly, up until certain amount of traffic, which I’ll never reach.
JWT is a standard that comes with all of the benefits I described above and is used by many services that I can take advantage of. If the article tells me to switch back to some session id based scheme because it is supposedly smaller, I think I’ll pass.
It’s a trade-off you make for not having to handle password persistence, and getting free-ish login/logout pages, SSO, MFA, password reset, etc. For many companies it’s a good trade-off.