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