Deprecation proposal

[foxx]

Having read through the docs, it would seem that JWT is now a better solution. It covers more use cases, has more language implementations and is also an RFC standard. Many of the languages, in particular Python, have much more active repos and commit history.

Is there anything in particular that itsdangerous does, which JWT does not cover? If not, I would like to propose deprecating this library in favour of JWT.

[mitsuhiko]

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 :)

[foxx]

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.

[mitsuhiko]

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.

[foxx]

Interesting insights, thank you for sharing!