Deprecation proposal about itsdangerous HOT 4 CLOSED

I find JWT tricky to use securely which is why I avoid it like the plague whenever I can for my own stuff. You cannot avoid JWT much for external interoperability obviously but I will not deprecate itsdangerous as a result :)

from itsdangerous.

Thanks for the quick reply. Just out of curiosity, which aspect of JWT security do you find tricky to use? There were several implementation bugs a while back, e.g. none algo being allowed by default, but those have all been fixed now.

from itsdangerous.

none is just the obvious example but the entire algorithm negotation is not thought through well. You would need to match the algorithm exactly against what you issued with a sliding window for potential upgrades and not a single JWT library supports this. none was just obviously broken because it disable the signature entirely. But you can still downgrade to signature to the shittiest version someone accepts. This is particularly problematic if a public part of one protocol becomes the private part of another.

For instance the server thinks it will get an RSA token but you actually send an HMAC token then the public part of the RSA key will be used for the secret of the HMAC token. But this is just an example, there are many more cases where libraries completely fail currently.

JWT is just too complex of a system that people would write good implementations for.

from itsdangerous.

Interesting insights, thank you for sharing!

from itsdangerous.