I've never said JWT is insecure. It's just hard to do it right, even with libraries. Most libraries just give you HERE IS THE SIGNED TOKEN, but everything else is on you. I've implemented JWT many, many times, and I'm really tired of implementing the same thing over and over again. Most of the things you do is boilerplate, but If you never thought about this boilerplate you're vulnerable.
It can be done right, but it's harder than doing something else.
Take it like this: IF YOU KNOW WHAT YOU ARE DOING, OK, FINE, GOOD LUCK
IF YOU DONT, STICK TO SOMETHING SIMPLER.
Simple solutions are better solutions, and developer time is important. Do you want to maintain simple authentication layer or you want this complex machinery, upgrade library, check for CVE, validate the library implementation, read the RFC. At that point I would be like... NO, I wanna go and do other things I'm interested in.
Yes you can invalidate them, but comes at the cost that you have to write the machinery yourself, that is the point. If you miss something, that's security issues, and I say you can't just because people are not doing it, dont know about it, or think ITS SIGNED, I DONT HAVE TO DO ANYTHING ELSE. Which is false pretenses. Also term invalidation is kinda tricky. YOU CANNOT INVALIDATE IT in a sense token is invalid. It's backlist invalidation, you store it and say this is invalid if you encounter it. You can say it's the same thing for session, yes and no, session have to be stored, deleting them is invalidating them, jwt is build on promise that you dont need to do all this, and this is the pitfall.
> Sure, agreed, but so what? It's a feature that no one uses. That doesn't invalidate other features of jwts.
True is unused feature, but then stateless part falls apart, you don't save anything but introduce complexity and maintainance problems, someone will have to go over that code, understand it and not crew things up.
> I think this misses the mark a bit. Signing/validating a jwt can be done entirely on your application server, which should easily scale horizontally. Any kind of db lookup requires a roundtrip/bottleneck which introduces complexity. So, even if it's the same # of ms, there's still an inherent advantage for validating on your application server IMO.
My position here is, if I have to hit the database, well why then I need the signing part, or encryption part, whats the benefit of it. What I understand from JWT, you dont have to store anything. That was the promise of it, and yet for secure systems you have to store something, at least to be GDPR compliant. AFAIK you need to provide the feature LOGOUT FROM EVERYTHING by GDPR, dont quote me on that, it's what I've seen, not a lawyer, simple developer.
All I'm saying is that if you clearly can, then don't claim that you can't. Maybe claim it's inconvenient or impractical, but it's an absurd paragraph in the original article.
> True is unused feature, but then stateless part falls apart
Maybe a miscommunication, but that part of my comment was referring to validating the token on the client. I don't see how this makes them not stateless. The stateful/statelessness can be entirely confined to the server.
> My position here is, if I have to hit the database, well why then I need the signing part, or encryption part, whats the benefit of it.
It provides a useful token that can be validated once by some kind of front end application server, and then passed around from there to backend microservices which trust the validation from the front end app server. None of the backend microservices need to hit the database again. I tend to agree that the signing/encryption parts are not particularly useful, but that doesn't make jwt a scam (the premise of the article).
> yet for secure systems you have to store something, at least to be GDPR compliant. AFAIK you need to provide the feature LOGOUT FROM EVERYTHING by GDPR, dont quote me on that, it's what I've seen, not a lawyer, simple developer.
To do this minimally, you don't have to store anything under normal conditions. You only have to store the ids of revoked tokens, and only for the lifetime of the token that is invalidated.
It's not, it's just something that I've had problem with a long time. Not everything is AI generated, and I hate if someone writes AI articles especially something important like this. These are my general thoughts about it, everything here that I explained is the things I've seen in the wild, and what people are doing. I'm just fed up with it
One thing that I did AI generate is the website itself. I really didn't have the time to do it on my own and I vibe coded it
Attacking another user like this is not acceptable, regardless of how/whether they used an LLM. It just adds poison to the site and community you're trying to defend. Please don't do that.
Users have different understandings of how to use LLMs appropriately. That's normal, since society is just beginning to figure this out. New users to HN should be welcomed, not attacked, and respectfully given information about local norms*.
This issue is complex with non-native English speakers, many of whom are using LLMs to try to improve their English. Often they aren't generating text outright but asking an LLM to edit it, and they don't realize that doing this can leave as many LLM imprints on their text as generating it outright.
* The explanation part could go like this: (1) LLM-generated/edited comments aren't allowed on HN (https://qht.co/newsguidelines.html); (2) the community mostly doesn't want to read LLM-generated/edited articles either; (3) there is little if any difference between using an LLM to edit text vs. generate it outright - the community will react much the same either way.
I'm not, first of all, English is not my first language and I dont see any problems with this sentence. This is not AI, and I'm not lying, but you can believe in whatever you want, I really dont care
(Normally I wouldn't duplicate a comment but this information applies equally to both your post and Tiberium's.)
Attacking another user like this is not acceptable, regardless of how/whether they used an LLM. It just adds poison to the site and community you're trying to defend. Please don't do that.
Users have different understandings of how to use LLMs appropriately. That's normal, since society is just beginning to figure this out. New users to HN should be welcomed, not attacked, and respectfully given information about local norms*.
This issue is complex with non-native English speakers, many of whom are using LLMs to try to improve their English. Often they aren't generating text outright but asking an LLM to edit it, and they don't realize that doing this can leave as many LLM imprints on their text as generating it outright.
* The explanation part could go like this: (1) LLM-generated/edited comments aren't allowed on HN (https://qht.co/newsguidelines.html); (2) the community mostly doesn't want to read LLM-generated/edited articles either; (3) there is little if any difference between using an LLM to edit text vs. generate it outright - the community will react much the same either way.
Is revocation really such a hard problem? Seems you could store a set of revoked tokens in memory and have a background task update it every couple of seconds. I guess it’s a separate set of infrastructure to maintain but I don’t see why it’s always presented as the thing that undermines an entire authentication scheme.
I guess if you need your tokens revoked this millisecond it’ll require an extra synchronous call on every request but that seems like a unlikely requirement. And not that any of this matter for your 10 user app anyway I guess.
Still the same problem, if your account is compromised, you cannot invalidate the session, same for web, same for native app. You need to store it so that it can be blacklisted.
How that is possible, when every web framework has a package for handling sessions, and in a secure manner. Rolling everything on your own is time consuming and error prone. I know you should not use library for everything, but this is solved problem for a long long time (like crypto), and just using of the shelf solution is right choice to me. You can set the session to be across multiple subdomains and it will work out of the box.
Eveything else can use plain tokens stored in the DB
Yeah... but you can't just move a session across a heterogeneous set of servers with different backends, etc... Maybe some of your APIs are on one platform, the apps themselves on another. There are several libs that can help you do that.
JWT is not a solution for that, any regular token fixes this problem. If you need something like that you can build an auth server, and everybody talks to auth server. I've built these kinds of systems, they are complex and working on them is not fun, you have to be really careful not to mess things up and if I have to worry about JWT as well, this is one more problem in a distributed system that if I can avoid, I would gladly.
TBH, I've not found use case for JWTs, maybe I'm not experienced enough and if it's there, there must be a use case for it. But I've found that there are simpler authentication schemes you can do, and I try to do them instead of implementing JWT.
What are you talking about? Good frameworks have support for using guards on endpoints. Typically you add an annotation to the handler and that's it - and your system is then going to be much more secure than most alternative approaches, because the simple one-line guard ensures that only users who are authorized to access a specific resource can access it.
You just haven't understood what JWTs are good for. See my other comment in this thread.
It can be done right, but it's harder than doing something else. Take it like this: IF YOU KNOW WHAT YOU ARE DOING, OK, FINE, GOOD LUCK IF YOU DONT, STICK TO SOMETHING SIMPLER.
Simple solutions are better solutions, and developer time is important. Do you want to maintain simple authentication layer or you want this complex machinery, upgrade library, check for CVE, validate the library implementation, read the RFC. At that point I would be like... NO, I wanna go and do other things I'm interested in.