Why must the sub (Subject) claim in JWTs be an immutable static user ID?
❓ Interview Prompt: Explain RFC 7519 sub claim rules, mutable vs immutable attributes, email address updates, and identity stability.
RFC 7519 defines the 'sub' (Subject) claim as the principal identifier about which the JWT claims are asserted.
Critical Security Rule:
The 'sub' claim MUST be an immutable, permanent surrogate key (e.g. UUID 'usr_99218412'), NEVER a mutable user attribute (such as an email address or username).
Why Email in 'sub' Causes Security Bugs:
If a user changes their email address from 'alice@old.com' to 'alice@new.com', or if an organization recycles 'alice@old.com' to a new employee, existing tokens or database foreign keys tied to 'sub: "alice@old.com"' grant unauthorized access to the wrong person!
Code Implementation Example
// INSECURE: Mutable email used as sub claim
const badPayload = { sub: 'alice@company.com' };
// SECURE: Immutable UUID used as sub claim; email stored as standard claim
const securePayload = {
sub: 'usr_01H8X92K4Z00', // Immutable static surrogate key
email: 'alice@company.com'
};The JWT sub claim must be an immutable static surrogate ID, never a mutable attribute like an email address.