What do a JWT's iss, sub, aud, exp and iat claims mean?
answer
- Who made it, who it is about, who it is for
- Two of them are timestamps
- A shared vocabulary, not a mandate
- One stops replay across services
- All of them are optional in the format
basics
~20 siss names who issued the token, sub the principal the claims describe, aud the intended recipients, exp the moment from which it must not be accepted, and iat when it was issued. All are optional registered claim names.
solid answer
~50 sThese are *registered* claim names — a shared vocabulary so independent systems agree on meaning. **`iss`** identifies the issuer, the party that minted and signed the token. **`sub`** identifies the subject, the principal the claims are statements about — typically the user, sometimes a service. **`aud`** identifies the intended recipients; a recipient is expected to find itself named there and reject the token otherwise. **`exp`** is the expiry: on or after this time the token must not be accepted. **`iat`** records when the token was issued, which lets a recipient reason about its age independently of expiry. Values of `iss`, `sub` and `aud` are strings (URI-shaped values are common); `exp` and `iat` are numeric timestamps. Every one is optional in the format itself — the specification defines what they *mean*, while your application decides which it requires.
code
json · 8 lines{
"iss": "https://auth.example.com",
"sub": "user-42",
"aud": "https://billing.example.com",
"iat": 1767225600,
"exp": 1767229200,
"jti": "3f8b1c9e-0a2d-4c77-9f1e-6b5a2d0c7e14"
}go deeper
Be able to expand each abbreviation and give a one-line meaning without hesitation. This is a rapid-fire screening question and hesitation reads as inexperience.
Explain that these names are registered vocabulary rather than mandatory fields, and that a claim only does something when a verifier acts on it.
Show you decide per service which claims are required, and that you use iss and aud to keep tokens from one service or issuer from being honoured by another.
Own the claim contract across the platform: which claims every token carries, who may add more, and how services avoid becoming coupled through an informal shared payload schema.
## 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.
- Are any of these claims required for a token to be a valid JWT?No. The format defines their meaning, not their presence — a payload with no registered claims at all is still a well-formed JWT. Requirements come from the application or a profile: an access-token profile may demand iss, sub, aud and exp, and a verifier should refuse tokens missing what it requires.
- What is the difference between iss and aud?iss names who minted and signed the token; aud names who it was minted for. iss selects whose keys and whose statements you are evaluating; aud tells you whether this token was meant for *you*. A token can be perfectly authentic — right issuer, valid signature — and still be addressed to a different service.
- Why keep iat when the token already carries exp?They answer different questions. exp says when to stop accepting; iat says how old the token is. Age enables policies expiry cannot express — requiring a recently issued token for a sensitive action, or rejecting every token issued before a credential change by comparing iat to a per-user cutoff.
saying these in an interview costs you the question
- Says sub is the token's subject line or purpose
- Confuses iss with aud
- Believes the claims are mandatory in every JWT
- Thinks including exp expires the token automatically
- Treats claims as authoritative before verifying the signature