iat should not be used for token lifetime validation

[nicosabena]

The exp and nbf claims should be used to validate the token lifetime, but the iat should be treated as merely informative.
The JWT spec does not indicate any validation for iat. Other libraries like .Net also don't use iat (e.g. here).

[lbalmaceda]

I remember having this discussion with you. I'm open to remove the validation since like you said, the spec doesn't make any reference to the issued at for token validation. However, from my point of view (and maybe others) a token with an issued at date in the future doesn't make any sense. Tokens should "already been issued" by the time we're validating them, and how strict this check is can be easily tuned-up with the use of a leeway if that's causing issues.

That the spec doesn't mention something only means it's open for interpretation and the one we offer here is the one we agreed back when we set up this library. In this particular case, the spec only mentions that the iat claim is optional, reason why we don't fail a token validation if the value is not present at all.

I'll keep this issue open so we can have input from other users. Thanks for bringing up this topic.

[nicosabena]

Hey @lbalmaceda ! We had the discussion for another SDK, idtoken-verifier, and that resulted in this PR merged: auth0/idtoken-verifier@dc9a45d

[wuan]

We had issues with clock skew between servers which resulted in invalid tokens in rare cases. The logic added to our verifier which now sets a default leeway if no leeway is set could be removed if iat is not verified to be in the past.

[DinoChiesa]

Irrespective of clock skew (which can be handled by leeway), the spec has nothing to say about whether iat ought to be considered during validation. One may reasonably take either view: it should be considered, or it should be ignored.

On the side of "should be ignored" - already we have nbf and exp. These are validity times and are described as such. Therefore using iat as well as these properties would be redundant. By this reasoning the most sensible option is to ignore iat.

On the side of "should be considered" - common sense tells us that iat cannot be in the future. Any token with iat in the future looks bogus.

Libraries are free to adopt either view. java-jwt has taken the view that iat should be considered during validation. But users of libraries might differ, and it doesn't make sense to lock people into a view, given the silence in the spec on this point.

Therefore, a simple solution: Introduce a new method on the JWTVerifier class, ignoreIssuedAt(). This calls requireClaim(ISSUED_AT, null). Then also modify the verifyClaims() method and check for null on the ISSUED_AT claim, in which case no-op.

[DinoChiesa]

@lbalmaceda - any update on this idea?

[lbalmaceda]

I will accept a PR with a method like the one you suggested that disables the check. But by default, it should still perform that check.

[complanboy2]

Hi @lbalmaceda, @DinoChiesa and @nicosabena

A PR is added for this #297, please have a look.