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

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.

Jan 07 '16 19:01 ryanflegel

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

Jan 10 '16 20:01 ryanflegel

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?

Mar 09 '16 03:03 lhazlewood

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).

Mar 17 '16 18:03 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:

exp and nbf which are automatically validated based on current datetime.
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.

Mar 19 '16 19:03 ryanflegel

What is the status of this PR?

Aug 29 '16 18:08 jd-carroll

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.