What do a JWT's iss, sub, aud, exp and iat claims mean?

## Why registered claims exist A JWT payload is an arbitrary JSON object, so without an agreed vocabulary two systems would invent different names for the same idea and no library could validate anything generically. The JWT specification therefore *registers* a small set of claim names with fixed meanings. Registering the name does not make it mandatory: the specification is explicit that use of each is optional. What it fixes is semantics — if you emit `exp`, it means expiry, and you may not repurpose it. ## iss — the issuer The party that created and signed the token. Its value is a string, and in practice it is almost always a URL identifying the authorization server or identity provider, because a URL is naturally collision-resistant across organizations. Its job is to tell the recipient *whose keys* should be used and whose statements these are. In a system that accepts tokens from more than one issuer, `iss` is what selects the trust configuration; in a single-issuer system it still matters, because a token from a different issuer that happens to verify against a shared secret would otherwise be accepted. ## sub — the subject The principal the claims are about. "The claims in a JWT are normally statements about the subject" is the specification's own phrasing, and it is a good mental model: everything else in the payload describes this entity. For a user-facing token that is a user identifier; for machine-to-machine tokens it is often the client or service identity. Its value must be unique at least within the issuer's namespace. ## aud — the audience Who the token was minted *for*. The value is a string, or an array of strings when a token is intended for several recipients. The semantics are recipient-directed: each recipient is expected to look for a value that identifies itself. This is what stops a token from being replayed across services — a token minted for the billing API should not be usable at the admin API, even though both trust the same issuer and both would find the signature valid. ## exp — expiry A numeric timestamp: on or after this instant the token must not be accepted. It is the format's only built-in lifetime control, and it is what makes a self-contained token tolerable at all, because a token you cannot look up is one you can only stop honouring by waiting. Short lifetimes shrink the window in which a leaked token is useful. ## iat — issued at When the token was minted. It is distinct from expiry: `exp` says when to stop accepting, `iat` says how old this token is. That enables policies expiry alone cannot express — refusing tokens older than a threshold for a sensitive operation even if they have not yet expired, or invalidating every token issued before a password change by comparing `iat` against a per-user timestamp. ## nbf and jti Two more registered names round out the set: `nbf` ("not before") marks the start of the validity window, and `jti` carries a unique identifier for the token itself. ## Presence versus meaning The most common junior mistake is treating a claim's *presence* as protection. A payload containing `exp` does nothing on its own; some verifier has to read it and refuse the token. Equally, a claim that is present and readable is not authoritative until the token's signature has been checked — until then the whole payload is attacker-supplied text. Knowing the vocabulary is step one; knowing that something must act on it is what the rest of the topic is about.