The change made in #332 has makes it hard to figure out what is going wrong when a token is rejected for having the wrong audience. I already check for this in my application code and provide a meaningful error, but without some way to decode the JWT to understand what aud was sent I cannot convert my code to utilize this new version without doing manual base64 + serde_json deserialization.
While I agree this change is necessary to match the spec, I'd like to suggest that a similar method to Validation::insecure_disable_signature_validation is introduced to aid in inspecting invalid JWTs.
Storing the rejected aud in the error type would also work, but I suspect this is less desirable for this crate.
The change made in #332 has makes it hard to figure out what is going wrong when a token is rejected for having the wrong audience. I already check for this in my application code and provide a meaningful error, but without some way to decode the JWT to understand what
audwas sent I cannot convert my code to utilize this new version without doing manualbase64+serde_jsondeserialization.While I agree this change is necessary to match the spec, I'd like to suggest that a similar method to
Validation::insecure_disable_signature_validationis introduced to aid in inspecting invalid JWTs.Storing the rejected
audin the error type would also work, but I suspect this is less desirable for this crate.