What does a JWT's sub claim identify, and why is sub alone not a global user identifier?

## What sub means The subject claim identifies the principal that the JWT's claims are statements about. The specification's own framing is that "the claims in a JWT are normally statements about the subject", which is the cleanest way to remember it: if the payload says `role: admin`, it is asserting that *the subject* is an admin. For an interactive session that principal is the end user; for machine-to-machine tokens it is commonly the calling client or service identity. ## The uniqueness rule and why it bites The requirement is that `sub` be unique *in the context of the issuer*, or globally unique. That is a weak guarantee by design, because forcing global uniqueness on every issuer would mean mandating UUIDs or URIs everywhere. In practice issuers take the local option and emit database identifiers, so subject values collide freely across issuers. The consequence is concrete. A service that accepts tokens from a corporate directory, a consumer identity provider and its own login service will see the value `"1001"` from all three, meaning three unrelated people. Storing users keyed on `sub` alone merges those accounts: whoever authenticates second inherits the first person's data. The fix is to treat the identity key as the **(issuer, subject)** pair — store both columns, key the unique constraint on both, and compare both on every lookup. That is why identity libraries and account-linking schemas are built around the pair rather than the subject alone. ## Stability: never let sub change The second property you need is that the value is durable. It should not change while the account exists, and it must never be reassigned to a different principal after the original is deleted. Two anti-patterns break this: - **Mutable identifiers as sub.** Email addresses and usernames are the usual offenders. A user changes their email and, to every relying service, becomes a brand-new person with an empty account — or worse, an old address is released and assigned to someone else, who then inherits the previous holder's records. - **Recycled database ids.** A table that reuses identifiers after deletion has the same effect on a smaller scale. The robust choice is an opaque, immutable, never-reused surrogate: a UUID or an internal id that is generated once and only ever retired. Note that this is a property of how the *issuer* mints subjects — a relying party cannot fix it and can only detect the damage after the fact, which is why it is worth asking about when integrating a new identity provider. ## Opacity and format The value is a string, and URI-shaped values are permitted, which is how some issuers achieve global uniqueness. Relying parties should treat it as **opaque**: do not parse it, do not infer a tenant from a prefix, do not assume it is numeric, and do not assume a length. Comparison is exact string comparison — no case folding, no trimming, no Unicode normalization; those transformations either merge distinct subjects or fail to match the same one. ## Privacy Because the payload is readable by anyone holding the token, `sub` is a disclosed identifier. Using a raw email address exposes personal data to every log and client that sees the token; using an internal database id exposes an enumerable key and hints at your data's size. An opaque random identifier avoids both, and issuers serving multiple relying parties sometimes go further by emitting a different subject value to each one so that two services cannot correlate the same user. ## What interviewers are checking That you know `sub` is the principal and not the token's purpose; that you can state the (`iss`, `sub`) pairing rule and why it exists; and that you recognize mutable or reusable identifiers as an account-takeover hazard rather than a cosmetic choice.