iat (Issued At) Claim in a JWT

iat states when the issuer built the token, using the same NumericDate seconds count as exp and nbf. On its own it grants and denies nothing: a verifier that reads iat and no exp has learned the token's age and still has no rule about when to stop accepting it. Its value is as a reference point that other rules are written against.

Two rules commonly lean on it. An application can impose a maximum acceptable age independently of the issuer's own exp, which is useful when a service wants tighter freshness than the identity provider offers. And when a re-authentication was requested with max_age, the relying party compares auth_time rather than iat, because iat only says when this token was minted, which may be long after the person actually typed a password.

Because the issuer writes iat from its own clock, a value in the future means the two clocks disagree rather than that anything malicious happened, at least usually. Verifiers therefore treat a slightly future iat as tolerable and a wildly future one as a defect. Any check written against iat needs the same leeway that exp checks need, for the same reason.

The decoder converts iat to a readable local timestamp, derives the token's age from it, and derives the intended lifetime from the gap between iat and exp, which feeds the lifetime progress bar. Its validation list warns when iat is more than sixty seconds in the future, and raises an error when exp is less than or equal to iat, since a token cannot expire before it existed.