-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[proposal] Improvements to the verification API #239
Labels
Comments
mirceanis
pushed a commit
that referenced
this issue
Aug 12, 2022
) relates to #239, partially closes it
mirceanis
added a commit
that referenced
this issue
Aug 15, 2022
mirceanis
added a commit
that referenced
this issue
Aug 18, 2022
🎉 This issue has been resolved in version 6.5.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
The verification of JWT/JWS uses exceptions to signal failures, but this creates a problem in distinguishing between legitimate failures (bad signature, invalid audience, timestamp issue, etc) and exceptional situations (network timeout while resolving DID, malformed input, unsupported algorithm, etc).
I propose separating these 2 scenarios internally so that users get a better idea about what failed and so that control flow for invalid JWTs no longer relies on parsing error messages.
Describe the solution you'd like
The result of
verifyJWT()
should be an object with averified
property set to true only when signature, timestamps, and audience are valid, and false otherwise.When one of the validation criteria fails, the reason can be returned as an error code with a message.
verifyJWT()
should not throw errors.The verification options should accept a
now
parameter for checks involving past/future validity, or allow the user to disable timestamp checking. Similarly, it should be possible to skip audience checking (although, this is already indirectly possible by pre-inspecting the desired audience).Describe alternatives you've considered
The desired behavior can already be achieved by calling
verifyJWS
directly for signature checks and by performing timestamp and audience checking out of band, but that defeats the purpose of having a library to do this.Another acceptable solution would be to introduce a new method (
verifyJWTSafe
) that can give detailed reasons for failure without using exceptions for flow control, while leaving the existingverifyJWT
method intact for backward compatibility.Please add your opinion about this subject if you have one.
The text was updated successfully, but these errors were encountered: