| > Yes you can invalidate them 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. |