Add ignoreExpiry(), ignoreNotBefore() and ignoreSignature() to JwtPa…

[ryanflegel]

Add ignoreExpiry(), ignoreNotBefore() and ignoreSignature() to JwtParser to skip validations when parsing JWT.

I need to parse some information out of the token, but I'm not too concerned about the validity of the token.

In particular, I'm extracting the subject for logging and the token will either already be validated (I don't have the key) and I would still like to log the username (subject) in case of any errors, even if it can't be trusted.

[ryanflegel]

Looks like the CI build failed due to something environment related -- is there a way to run it again?

[lhazlewood]

Yeah, I'm fixing that now (Open JDK 7 was core dumping when Cobertura was enabled). That said, I don't think the current implementation approach is the right way to go: there are different validations that occur during parsing and we probably shouldn't add an ignore* method for every rule in existence.

Maybe something singular like validate(boolean validate) and if false, all validation is disabled. Thoughts?

[ryanflegel]

Yeah, you're probably right -- I was following the pattern used by require*. I think there are two main types of validations that should be able to be selectively ignored. The first is the signature validation and the second is the claims validations (iat, exp, nbf, etc).

[ryanflegel]

After taking a closer look, these seem to be the only validations that can't be configured, so I don't really see the list growing.

With respect to claims validations, there are currently two types:

1. exp and nbf which are automatically validated based on current datetime.
2. Any claim can be validated based on equality with require* methods. This includes exp and nbf.

I think configuring exp & nbf are a current gap in the current API, since require* only validates by equality and even then, the "nbf <= now < exp" that can't be disabled/configured. I see there are also a couple PRs around clock skew which is also a result of that. Perhaps the new API should address both these issues as one?

Just brainstorming here, but maybe instead of requireExpiry() and requireNotBefore(), they could be replaced by a more advanced validator interface. Here's an example of what i mean with some factory methods to keep it readable:

// Default would be equivalent to current validation: nbf <= now < exp

// Disables validation completely (my use case)
validateExpiry(DateValidator.disabled());

// Allow for a skew of 15 seconds: (nbf - 15s) <= now < (exp + 15s)
validateExpiry(DateValidator.allowClockSkew(15, TimeUnit.Seconds))

// Equivalent to requireExpiry(myDate)
validateExpiry(DateValidator.equalTo(myDate));

With respsect to signature validations, I think it still makes sense to have a validateSignature(boolean) and keep this independently configurable from claims validations.

[jd-carroll]

What is the status of this PR?

[selimok]

Hi, are there any decision to merge this change into master?

As part of our token expiration strategy, we create tokens with short life spans and re-create new tokens if needed. To do this in more convenient way, we need aforementioned ignore methods while parsing.

Thanks.

[lhazlewood]

Quite possibly - we'll double check since there seems to be more interest.

[nvasilescu]

I need this also. To be able to read claims from an expired token.

[emeraquino]

Any news regarding the status of this of PR?

[djensen47]

Is there any other way to get claims without checking expiration or signature?

[lhazlewood]

Closing just as a matter of housekeeping - this will be implemented/tracked under #474