Would you consider changing the methods you expose so as to avoid common JWT mistakes?

[oskarpearson]

Would you consider changing the methods you expose so as to avoid common JWT mistakes?

For context: In reviewing the code for the "keycloak gem" I found imagov/keycloak#33 (comment)

This sort of issue is, unfortunately, extremely common.

The concern I have is that the implications of supplying "false" to JWT.decode aren't very clear to someone using this gem (ruby-jwt).

It seems like if we had a "sensible baseline" method that did "the right thing" as the main interface for using this gem, and then had "clearly unsafe" ways of interacting with the gem when needing to get at the internals, it would help prevent this sort of foot-gun.

#528 and #433 have related discussions.

If one was to create the equivalent of https://libsodium.gitbook.io/doc for parsing and handling JWTs in ruby, what would it look like?

[anakinj]

Thank you for raising this issue @oskarpearson. Changing the JWT.decode API is unfortunately not super straight forward because of its wide adaptation. Im very tempted in just deprecating that but keeping it for backwards compatibility.

The newer object based approach in JWT::EncodedToken introduces some protection against common pitfalls for example by:

• Not allowing access to the payload before verifying the signature and claims
• If you really want to access the unverified payload, you need to do it via the #unverified_payload

Currently the default verification is signature validity and exp claim

I have been hesitant to change the documentation to point to the new api as it's pretty fresh out of the oven. But that would be the ultimate point to only have one recommended way to use the gem.