111–120 of 335 posts
=0 I stumbled across this post and was thinking that it's interesting to see this topic trending now, since I've done a lot of work on it in the past. Then I clicked through and realized the author is linking to some of my stuff! What a blast from the past. Anyhow, there are way smarter people than myself who have covered this topic extensively over the years, but I still think that, even in 2026, JWTs are the wrong…
Invalid certificate - dark humor. https://www.paseto.io/
Earlier quoted context omitted.
> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…
> if you have to check an identifier for revocation on every request you could just use an opaque session ID and look that up on every request instead! One reason could be the size. A revocation list only needs to keep session IDs of recently logged-out sessions, for which the token's TTL hasn't yet expired. It may be a much smaller list than a list of every active session. Also, a JWT (or a Macaroon, etc) can store…
It seems they were not of very much use in the past, but with the agentic-everything now, I see this as a great way of delegating permissions to subagents, third-party agents, etc.
Working on something along these lines but unfortunately I cannot dedicate as much time as I'd like.
Still, if anyone is reading, give Macaroons a try!
Earlier quoted context omitted.
> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…
Stateless JWT revocation: https://blog.nellcorp.com/new-aproach-to-jwt-revocation/
Earlier quoted context omitted.
Spec writers and library authors are human? Who knew
I don't understand what this is meant to communicate. The standard is either good or it isn't. "Good effort" is not an engineering assessment.
If everyone simply designed everything right from the beginning we would live in nirvana.
Earlier quoted context omitted.
I don't understand what this is meant to communicate. The standard is either good or it isn't. "Good effort" is not an engineering assessment.
Your objection is that they should be "designing it right from the beginning" but that applies to all realms of endeavour. The reason they didn't is human frailty. If everyone simply designed everything right from the beginning we would live in nirvana.
Earlier quoted context omitted.
If your talking about a browser context, where the authority is separate from the requesting body, then expiring even at 30s is excessive for user context, let alone every 1s or every request... you're effectively then inflating every single API request into 2 requests... one for a new token, then another to the API being called. This is irresponsible for not much gain in a user-facing context.
You should not be using them for user contexts at all. The cookie should be the session token and the sessions should be stored on the server side where you can simply delete them and the user's login becomes invalid. Using JWTs for this use case is just plain wrong.
You can use a revocation list with JWT if necessary, and if your JWTs never last more than 15m you'll be fine.. and if your security window is tighter than that, you probably have bigger issues to deal with.
Earlier quoted context omitted.
> Necessary qualifier: for browser-based user sessions. > Plenty of good uses for JWTs for service-to-service communication. This is the sensible conclusion right there. I agree JWTs are the wrong tool for the use case of user sessions in the browser. To give some more arguments: All the signature and encryption stuff in JWTs is complex. While common JWT libraries have now mostly got their stuff together, this has no…
Stateless JWT revocation: https://blog.nellcorp.com/new-aproach-to-jwt-revocation/
> ALTER TABLE users ADD COLUMN token_secret;
So it's "stateless" but we have to query the users database on every request? How is that more stateless than SELECT * FROM session WHERE id = cookie?
Ignoring that and taking the mechanism as given: Why the obsession with cryptography, in this case HMAC? I don't see any reason why another signature is needed here when I believe the same outcome could be accomplished with a token_epoch field in both the signed JWT and the users table. Just increment the epoch to revome old tokens. Or even better, drop the epoch field and have an iat_not_before field per user. The field in the JWT is signed, the whole point is that you can trust it.
Do let me know if I miss anything here please. Assuming I haven't: it's always puzzling to me to see people being so eager to sprinkle more cryptography on anything that is supposed to be secure. For me, I've become more afraid of cryptography the more I learned about it. Cryptography is hard. It's not a magic ingredient for security. At best, it's dangerous black magic -- very potent, but pronounce a single syllable of your magic spell wrong and it _will_ blow up in your face.
No need to stop. The XSS argument also applies when using cookies. JWTs are just tokens like session data but in JSON format. What format you choose to go with doesn't matter. You can keep storing JWTs in local storage and still be secure. Discord removes it on page load and restores it when the tab is closed. Also if your website is susceptible to XSS, skill issue, exactly like in the case of SQL injections. That wo…
A lot of times local storage is much less secure than using cookies. Cookies have about 20 years of infra built around it (HttpOnly, SameSite, Secure, etc). There's some weird parts about cookies, but local storage really shouldn't be used for anything security sensitive
Is it? If an attacker can't do XSS then it's as strong as cookies.
Supply chain attacks aren't an argument here because they can also happen with cookies. CSRF as well. The same can happen in actual executable binaries.
I don't get the 20 yr age argument:
- HttpOnly fights XSS which is impossible to execute with modern frontend frameworks.
- SameSite fights CSRF but the real solution is to disable loading the website in iframes (remember clickjacking?).
- Secure fights MITM which is already fixed by default when using local storage and HSTS is the real deal.
Having said that, I'd say that local storage is more secure than cookies (no need to remember whether you put Secure on or not). Unless you're still using PHP, which means touch grass.
Earlier quoted context omitted.
Your objection is that they should be "designing it right from the beginning" but that applies to all realms of endeavour. The reason they didn't is human frailty. If everyone simply designed everything right from the beginning we would live in nirvana.
You've completely missed my point. I don't even accept the premise of the JWT standard. But the eventual migration to safer default settings, in a format that continues to expend implementation effort to support settings nobody should use, is in fact a practical engineering problem with the standard.
I'd rather use a refined, battle-tested standard with lots of eyes on it than some new untested contender produced by a handful of upstarts ("look, we just designed it right from the beginning! This time it's perfect!") PASETO reeks of second-system syndrome.