sub (Subject) Claim in a JWT

RFC 7519 says the subject value must be locally unique in the context of the issuer, or globally unique. That word locally is the whole story: an issuer promises the identifier is stable and unambiguous inside its own directory and promises nothing outside it. OpenID Connect adds that the value must never be reassigned to a different person, which is the property that lets you use it as an account key.

Identity providers issue two shapes of subject. A public subject is the same string for every application connected to that provider. A pairwise subject is derived per client, so the same human appears as a different sub to each application, which stops two relying parties from correlating their user lists. Switching an application between the two, or moving it to a new client registration, changes every sub it will ever see.

Nothing requires sub to be readable, and putting a readable value there costs you later. An email address in sub breaks the never reassigned rule the first time someone changes address and the old one gets recycled. An incrementing integer leaks how many accounts exist. An opaque random identifier avoids both and gives away nothing about the directory behind it.

The decoder shows sub under Registered claims labelled Subject with its raw value, and lists an informational item when the claim is absent. It makes no attempt to look the subject up anywhere, which is the point: the token you paste never leaves your browser, so a production subject identifier is safe to inspect.