I'm using JWTs for user auth in a web application. I have a user db where each user's unique ID is their email address. To identify the subject of the JWT, I currently have a claim which stores the user's email address in the token. Does that pose a security problem? If so, should I be using a GUID or a hash of the email address as an ID?
Yes, it is bad practice and a security problem.
Email addresses are PII (personally identifiable information). Like all other PII, email addresses should never be stored unencrypted at rest; doing so is inherently insecure.
If your JWTs are going to be stored at rest anywhere - such as a database, or local or session storage in the browser - then you should not use any claims in your JWT that expose PII.
The fact that
address, but that's all PII too.
I have a user DB where each user's unique ID is their email ...
Well, there's a protected claim for users' ID. The claim
4.1.2. "sub" (Subject) Claim
The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
Perhaps, it would be more appropriated to use the claim
sub instead of
That said, nothing prevents you from implementing both
It's commonplace to store a user's e-mail address in a token.
The properties of said e-mail address are up to the identity provider (is it unique, can it be changed etc.)
A few scenarios which are potentially insecure are a user changing their e-mail address and another user then taking up that e-mail address. Or a user deleting their account and re-creating that account under the same e-mail address. There is also a risk of an admin inadvertently unchecking the "enforce unique e-mail addresses" checkbox in the identity provider's configuration (if present)
You would also be mindful of this e-mail address leaking PII into logs and reporting.
When using an UUID or other non-guessable, stable identifier most of these issues are avoided. When a new account is created it receives a new UUID thus becomes a new identity whereas the e-mail address can be changed and it will stay the same identity.