Why validate that 'iat' is not in the future?

In https://github.com/jpadilla/pyjwt/blob/c5ee34e86bc42bef60ef6e701df569c2c86a5d5d/jwt/api_jwt.py#L129:

if iat > (now + leeway):
    raise InvalidIssuedAtError('Issued At claim (iat) cannot be in'
                               ' the future.')

I just debugged an issue in prod where jwt.decode() failed because of this. Mostly because the other party’s jwt lib added ‘iat’ a few seconds or minutes ahead of our clock time (‘clock skew’ as mentioned in JWT specs).

I can’t find any place in the specs that says that a JWT should be invalid if ‘iat’ is in the future. It seems like it’s just there to be informative. I can use ‘nbf’ if I want to specify a “time before which the token MUST NOT be accepted for processing”

I consulted

• https://tools.ietf.org/html/rfc7519
• https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12

So either

1. I’m wrong and there is a JWT spec that says this is important to check. I want to know this, because if it’s out there, I shouldn’t just catch these errors from PyJWT and pass. Regardless of whether @jpadilla wants to remove that raise in his lib.
2. PyJWT is checking that unnecessarily, and we should remove it to be more compliant

[mark-adams]

RFC 7519 says:

The “iat” (issued at) claim identifies the time at which the JWT was issued.

In all circumstances except clock skew, it doesn’t seem like it makes any sense for a JWT to be valid if, by its own claim, it hasn’t been created yet. That’s why we included this validation. JWT doesn’t say you have to have this validation to be compliant, but it seems logical and enforces integrity in the data.

I’m against removing this validation, especially when you can already easily disable it by using jwt.decode(token, secret, options={'verify_iat': False}) or account for the clock skew by using the leeway parameter: jwt.decode(token, secret, leeway=10)

[ghost]

Hi, here’s a real word case of this issue causing problems.

Our infrastructure involves generating tokens on a server in Amazon’s cloud and checking them on another one in Google’s cloud using jwt.decode().

At midnight between 2016 December 31 and 2017 January 1, a leap second was introduced into UTC. Both clouds ‘smeared’ this second linearly over a period of time centered around that midnight: https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/ https://developers.google.com/time/smear

However, Amazon used 24 hour period and Google used 20 hour. This led to Amazon’s clock being ahead of Google’s on December 31 between 12:00:00 and 23:59:59, and our service was unavailable during most of that period due to jwt.decode() failing.