PASETO Reserved Claims (iss, sub, aud, exp, iat, nbf, jti)

PASETO inherits JWT's set of reserved registered claims, with one important presentation difference: timestamps are ISO 8601 strings rather than Unix seconds.

The standard claims:

{
  "iss": "https://auth.example.com",
  "sub": "user-12345",
  "aud": "https://api.example.com",
  "exp": "2026-01-01T00:00:00Z",
  "iat": "2025-12-31T23:00:00Z",
  "nbf": "2025-12-31T23:00:00Z",
  "jti": "01H6XJ9Y2Z3K..."
}

• iss (issuer) — the entity that minted the token. Must match the verifier's expected issuer.
• sub (subject) — who the token is about, typically a user ID or service account.
• aud (audience) — who the token is for. Verifiers should reject tokens that aren't addressed to them.
• exp (expiration) — ISO 8601 timestamp after which the token is invalid.
• iat (issued at) — when the token was minted; useful for "older than X" policies.
• nbf (not before) — token must not be accepted before this time. Useful for delayed activation.
• jti (token ID) — unique identifier, often a UUIDv7 or ULID, used for replay detection.

Validation order:

The PASETO spec recommends a specific validation order: verify the cryptographic signature/tag first, then check exp and nbf, then iss and aud. Doing it in any other order invites bypass bugs.

ISO 8601 quirks:

PASETO requires the Z-terminated UTC form: 2026-01-01T00:00:00Z, not +00:00. Some libraries accept either, but for maximum portability, always emit Z. Don't include sub-second precision unless your verifier is explicitly tolerant of it; the spec only requires whole-second resolution.

Custom claims:

You can add any JSON-serializable claim alongside the reserved ones. By convention, custom claim keys should be lowercase and use either snake_case or domain-prefixed identifiers (example_role, com_example_scope) to avoid collisions with future reserved claims.