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