View claims without verifying the signature?

[tyronedougherty]

Hi,
I've had a look and it doesn't appear there is a way to parse the claims in the JWT without specifically verifying the token. Is there a way to do this?

That would prove useful in a situation where you may have a dynamic secret.

Thanks! :)

[tyronedougherty]

I've submitted a pull request to expose the Parser so that this is possible, let me know what you think @robertjd :)

[lhazlewood]

If a JWS has a signature, not validating it violates the JWT specification. Do you expect njwt not to be spec-compliant?

An alternative:

Just strip off the last token in the JWT string (after the last period character) and take the resulting string and parse that. It is essentially an unsigned JWT at that point that the parser can validate in a spec-compliant manner.

[robertjd]

Hello @tyronedougherty , we have explicitly chosen to to not expose the parser because we want the public API of this library to enforce validation.

If a token fails validation, we do provide the parsed JSON objects on the error object. From the readme:

If validation fails you can look at err.message to understand the problem. If the header and body of the JWT were parse-able (not not verifiable) they will be provided as objects at err.parsedHeader and err.parsedBody.

I hope this helps.

Best,
Robert

[tyronedougherty]

Ah I see. My use case is in the situation where the signing secret is dynamic and unique to say a user, and you must therefore get information out of the body of the JWT to make a DB call that returns the secret unique to that user that you wish to use for verification.

Allowing for a standards based parser to extract the body of the JWT without necessarily having verified its authenticity against a signing secret, such as the one included in this package, is better than manually having to code your own extraction and parsing in my opinion, but I understand how it may unintentionally encourage circumvention of the verification process.

I'll try and use the err.parsedBody on verification for now, thanks!

[robertjd]

Good point! I assume you're using the kid field in the header to indicate which key was used to sign it? We don't yet support that in this library, but it's something I'd like to.

[tyronedougherty]

I did not actually know about the kid field, but that is interesting. It does seem to fit the use case I'm going after quite nicely. Thanks for this!