The Seven Registered Claims: iss, sub, aud, exp, nbf, iat, jti

JWTs are often treated as opaque blobs of security, but they are actually structured data packets governed by RFC 7519. This is Part 2 of the "JWT From the Spec Up" series. The specification defines seven "registered" claims. These are not optional decorations; they are the core mechanism by which a stateless token communicates its validity, origin, and scope to a relying party. Misunderstanding these claims leads to vulnerabilities like token replay, audience confusion, and indefinite session persistence.

This breakdown dissects each claim by its mechanism, not just its definition.

The Identity Axis: Who, From Where, and For Whom

The first three claims establish the triad of identity: the subject, the issuer, and the audience.

sub (Subject)

The sub claim identifies the principal that is the subject of the JWT. In most authentication flows, this is the user ID or email.

Mechanism: The sub claim is a string. It is not validated by the JWT library itself; it is validated by the application logic. The library merely extracts the string. The security implication is that sub does not prove identity; it asserts identity. The signature proves that the issuer signed this specific sub value. If an attacker can forge a signature, they can change the sub. Therefore, sub must be treated as a label assigned by the trusted issuer, not a fact verified by the verifier.

Example:

{
  "sub": "user-12345",
  ...
}

iss (Issuer)

The iss claim identifies the principal that issued the JWT. This is typically a URL or a unique identifier (e.g., auth.example.com).

Mechanism: The verifier must maintain a list of trusted issuers. When a token arrives, the verifier checks if token.iss exists in the trusted list. If not, the token is rejected. This prevents tokens from a compromised or malicious identity provider from being accepted by your service. Without iss validation, you might accept tokens from evil-auth.com if you only check the signature algorithm.

aud (Audience)

The aud claim identifies the recipients that the JWT is intended for. This is critical in microservices architectures where one service issues tokens that multiple services must consume.

Mechanism: aud can be a single string or an array of strings. The verifier checks if its own identifier is present in the aud claim. If the token is intended for Service A but arrives at Service B, and Service B validates that aud must contain Service B, the token is rejected. This prevents token reuse across unrelated services, limiting the blast radius of a token leak.

Example:

{
  "aud": ["api.example.com", "payments.example.com"]
}

The Temporal Axis: When Is This Valid?

Time-based claims prevent token replay and define the window of validity. They rely on integer arithmetic using the "Unix Epoch" (seconds since 1970-01-01T00:00:00Z). The interplay between exp, nbf, and iat creates a precise temporal envelope for the token's life.

exp (Expiration Time)

The exp claim identifies the expiration time on or after which the JWT must not be accepted for processing.

Mechanism: The verifier compares the current system time (now) against token.exp. If now >= exp, the token is invalid. This is the primary defense against token theft. If a token is stolen, it can only be used until exp. The standard mandates that exp must be validated. Failure to validate exp is a critical vulnerability, effectively creating an infinite session.

nbf (Not Before)

The nbf claim identifies the time before which the JWT must not be accepted for processing.

Mechanism: The verifier checks if now < token.nbf. If true, the token is rejected. This is useful for pre-issued tokens (e.g., a token generated for a future login time) or for ensuring that tokens issued before a key rotation are not used. It adds a temporal boundary to the left side of the validity window, working in concert with exp to define the active period.

iat (Issued At)

The iat claim identifies the time at which the JWT was issued.

Mechanism: This is a timestamp, not a validity constraint. It is used for auditing, debugging, and calculating token age. Some systems use iat to implement "sliding expiration" (e.g., refresh the token if it’s older than 24 hours, even if it hasn’t expired). While not strictly required for security, it is essential for operational visibility, providing the baseline from which exp and nbf are evaluated.

The Uniqueness Axis: Revocation in a Stateless Protocol

JWTs are stateless, meaning the server does not store session data. This makes revocation difficult. The jti claim provides a mechanism for stateful revocation within a stateless protocol.

jti (JWT ID)

The jti claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well.

Mechanism: jti is typically a UUID. When a token is issued, the server stores the jti in a short-lived cache (e.g., Redis) with a TTL equal to the token’s exp minus iat. If a user logs out, the server removes the jti from the cache. On subsequent requests, the server checks if the jti exists in the cache. If it does, the token is blacklisted and rejected. This allows for immediate revocation, which is impossible with purely stateless validation.

Conclusion

The seven registered claims form a complete security contract:

• sub, iss, aud define who and where.
• exp, nbf, iat define when.
• jti defines uniqueness for revocation.

Implementing these claims correctly is not optional. Skipping aud validation allows cross-service token reuse. Skipping exp validation allows indefinite token reuse. Skipping jti management makes revocation impossible. Treat these claims as protocol mechanisms, not metadata.