Guide Updated

JWT iat Claim (Issued At)

The JWT iat (issued at) claim is a Unix timestamp of when the token was created. Learn iat validation, max-age checks independent of exp, and why iat should never get clock-skew leeway.

The `iat` (issued at) claim is a Unix timestamp (seconds since epoch) identifying when the token was issued. It is defined in RFC 7519 §4.1.6.

Format and values

A numeric Unix timestamp in seconds. Example: `"iat": 1750087200`. Like `exp` and `nbf`, it is in seconds, not milliseconds.

Validation rule

`iat` enables maximum token age checks independent of `exp`: pass `maxAge` to your verify call to reject tokens older than a threshold regardless of `exp`. Never apply clock-skew leeway to `iat`: a token claiming to have been issued in the future is suspicious (possible replay or forgery), not a clock-synchronization issue. `iat` is also useful for audit logging: storing `iat` tells you exactly when each session was created.

Common mistakes

  • Applying clock-skew leeway to iat. A future iat is a red flag, not a clock-sync issue. Reject it.
  • Setting iat in milliseconds. Same trap as exp: use seconds.
  • Trusting iat before signature verification. Like every claim, iat is attacker-controlled until the signature is verified.

Code examples

Max-age check via iat (Node.js: jsonwebtoken)

Max-age check via iat (Node.js: jsonwebtoken) 
// Reject tokens older than 2 hours regardless of exp
const payload = jwt.verify(token, secret, {
  algorithms: ["HS256"],
  maxAge: "2h",
});

Max-age check (Python: PyJWT)

Max-age check (Python: PyJWT) 
payload = jwt.decode(
    token,
    secret,
    algorithms=["HS256"],
    options={"max_age": 7200},  # 2 hours in seconds
)

Frequently asked questions

  • What is the iat claim in a JWT?

    iat (issued at) is an RFC 7519 registered claim: a Unix timestamp in seconds identifying when the token was created. Its primary use is maximum token age checks (maxAge) independent of exp, and audit logging. Never apply clock-skew leeway to iat: a token claiming to be issued in the future is suspicious and should be rejected.

  • Why check iat if exp already limits the token lifetime?

    exp limits how long a token remains valid from issuance. iat plus maxAge limits how old a token can be when it is presented. These are different constraints. A token issued with a 24-hour exp that was actually created 12 hours ago by a compromised issuer is caught by maxAge: '2h' even though exp has not passed. iat also enables token rotation policies (re-issue if older than 5 minutes) and audit logging.

  • Should I apply clock skew leeway to JWT iat?

    No. A token claiming to have been issued in the future is a red flag for replay or forgery, not a clock-synchronization issue. Apply leeway only to exp and nbf. Rejecting a future iat is the safer default; tolerating it would let an attacker craft tokens that appear freshly issued.

Related