What is a JWT's jti claim for, and what uniqueness must the issuer guarantee?

## What jti identifies The JWT ID claim identifies *this token*. Not the subject — that is `sub`. Not the login session — a session may span many tokens, and each one gets its own `jti`. Not the request. If an issuer mints ten tokens for the same user in a minute, that is ten distinct `jti` values. ## The uniqueness requirement The specification is unusually explicit here: the value must be assigned in a manner that ensures a *negligible probability* that the same value will be accidentally assigned to a different token; and if the application uses multiple issuers, collisions must be prevented among values produced by different issuers as well. Two practical readings follow. First, "negligible probability" points at randomness with enough entropy — a version-4 UUID or a comparable random string — rather than at coordination. Second, the cross-issuer clause rules out anything scoped to one issuer's local state. A per-issuer sequence number satisfies uniqueness within one issuer and collides immediately across two. So do timestamps: two issuers minting in the same millisecond produce identical values, and a single issuer with concurrent requests can too. A random UUID sidesteps both problems without any coordination between issuers, which is why it is the default choice. A subtlety worth naming: even with cryptographically random values, `jti` is not itself a secret. It travels in a readable payload and appears in logs. It is an identifier, not a capability, and nothing should be authorized on the strength of knowing one. ## Comparison rules The value is a case-sensitive string. That matters because identifiers get passed through systems that like to normalize — a lower-casing log pipeline, a case-insensitive database collation, a trimming form binder. Any of those can turn two distinct tokens into apparent duplicates or make a stored value fail to match the token that produced it. Store and compare it byte-for-byte as text. ## What it is actually used for **Correlation.** The most common everyday use is diagnostic. Emitting `jti` in structured logs at each hop lets you follow one token through an authorization service, a gateway and several downstream services, and to answer questions like "which token was used for this action?" without logging the token itself — a real benefit, since logging the whole token would log a live credential. **Audit.** Recording `jti` alongside a sensitive action ties the action to the exact credential that authorized it, which is stronger evidence than "user X did this" when a credential may have been compromised. **A handle for per-token state.** When an application needs to track something about an individual token, `jti` is the natural key. Whether to keep such state at all — and what it costs — is a design decision with real tradeoffs; `jti` simply provides the identifier if you choose to. ## Inert unless consumed The most important thing to say in an interview is that including `jti` changes nothing by itself. A verifier that does not read it treats a token carrying `jti` identically to one without it. Candidates sometimes describe the claim as though its presence protects against reuse; it does not. It is a name, and names only matter when something looks them up. ## When to include it It is optional like every registered claim. Including it is cheap — a few dozen bytes — and pays for itself in traceability, so many issuers emit it unconditionally. The argument against is payload size on very hot paths, and even then the claim is small relative to a typical claims set.