JWT iat (Issued At) Claim

The iat (issued at) claim records when a JWT was created. Like exp and nbf, it uses the NumericDate format: seconds since the Unix epoch. While the iat claim is optional per the JWT specification (RFC 7519), it is strongly recommended because it provides essential context about the token's age.

Purpose and format:

{
  "sub": "user456",
  "iat": 1700000000,
  "exp": 1700003600
}

Here, iat: 1700000000 tells the server that this token was minted at that specific Unix timestamp. Combined with exp, it reveals the intended token lifetime (in this case, 3600 seconds or one hour).

How servers use iat:

Servers can use iat to enforce maximum token age policies independently of the exp claim. For example, a server might reject any token older than 24 hours even if its exp has not yet been reached. This is useful when security policies change and you want to invalidate tokens issued before a certain date, such as after a password reset or a security incident. A server can record the timestamp of the last credential change and reject tokens with an iat that predates it.

Relationship with other claims:

The iat claim is complementary to exp and nbf. While exp defines when a token stops being valid and nbf defines when it starts being valid, iat is purely informational: it records the creation moment. However, some libraries use iat to calculate exp if you specify a lifetime instead of an absolute expiration. For example, jsonwebtoken in Node.js lets you specify expiresIn: "1h" and automatically computes exp from iat.

Security considerations:

If a token has iat set far in the future, it could indicate clock manipulation or a forged token. Some validation libraries reject tokens where iat is in the future. Always validate that iat is a reasonable value when processing tokens. Also, never use iat as a substitute for exp; they serve different purposes.