3 ms·

Irrelevant. If the application doesn't call the function to verify the user token, the application is insecure, it doesn't matter what protocol or token format

• rileymat2 6y ago
  To play devils advocate say the design by the library was that you could not read the jwt data without the library verifying it. That goes away.
• andybak 6y ago
  You ignore the fact that some protocols are easier to "do wrong" than others. The point other people are making is that JWT is one of those. You're welcome to disagree but don't gloss over the fundamental point being made.
  • deleted 6y ago
    [deleted]
• chriswarbo 6y ago
  My response to that would be "Parse, don't validate" ( https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... ). In other words "the function to verify the user token" should also return the payload data (e.g. the user ID, or whatever), and it should ideally be the only way to get that payload data. That way there's very little that can go wrong: - If the verification function doesn't get called, then the application doesn't get its payload data (e.g. user ID), and hence can't be misusing that data. - If the application is using the payload data, then it must have come from the verification function, and hence has been validated. I'm adding JWTs to a system right now, and forcing this interface by encrypting all of the payloads. The only system with access to the decryption key will refuse to decrypt tokens which aren't signed, valid, non-expired, etc.
  • deleted 6y ago
    [deleted]