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.