Is it bad practice to store a user's email address in a JWT?

Question

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?

Answer 1

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 email is a registered IANA JWT claim is beside the point - so are given_name, middle_name, family_name, birthdate, phone_number, and address, but that's all PII too.

Answer 2

The short answer is no. There should not be any problem because email is a valid and registered public claim.

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 sub.

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 email because in your system the email is an ID and probably you want to treat as such regardless the format.

That said, nothing prevents you from implementing both sub and email. That's application-specific too.

From the security point of view, the main concerns should be at implementing the TLS (https) and the sign/encrypt of the token.

Answer 3

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.