Most of this article seems to be against having browser JavaScript store tokens and inject Authorization headers, which you are free to avoid if you don't want to use them. JWT is just a token format, you can set it as an HTTPS-only cookie and have your server read it from there. Stateful vs. stateless is orthogonal to how the token gets handled by the client and sent back to the server.
My toy projects I include the IP address in the JWT payload, so JWT is only good for that IP. I don't always see that in examples. Not sure any downsides of that
(if client is rotating IPs or VPN I may be blocking them anyway). But seems consistent with cookie concept that a login is only good on that device.
I think its a debate. I like to keep the db clean of sessions but easy enough to keep in server memory if I down the server I don't mind making people login again.
It's a bad idea... Users on mobile or use cellular connections get their IPs rotated often. There's also CGNAT (Carrier Grade NAT), users share a pool of IPs.
False. OIDC providers expose an API endpoint for early token revocation. Otherwise it would be impossible for users to LOGOUT.
The insertion of tons of junk metadata in a JWT's claims represents a problem of usage style, not an inherent problem of JWT or OIDC. As a workaround for good data design, the user can be presented with a re-authentication form, where the new token shall replace the old data.
Yep, and if you’re like “if you have to store a revocation/update list then isn’t that just a stateful session again?” Yes but now you only have to store the changed tokens instead of every token — good trick if you’re having trouble scaling Redis.
yeah, JWT's are a nice standard way of doing that, but it's functionally not really different than the HTTPS + Session + Nonce pattern that's been in use for about 10 years now, and, provided you pick a secure function to make the hash for the nonce, the nonce may be more secure since it rotates with each payload and the JWT's encryption lasts for its lifetime.
Every JWT auth system I've ever seen uses expiries on the order of minutes, and using a single-use refresh token to allow the client application to invisibly request an updated token.
