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?

  • It's not a security problem, if you do not mind potential leak of emails of your user base, however, there could be a problem with having an email as a unique identifier of a user within your system. I have seen it like 10 times, where email was used for unique identification and the business has decided to provide other means of authentication. If you can, prepare for that by using artificial identifier right from the get go. – Andy Sep 7 '17 at 6:53
  • 1
    Agreed. Here (Spain) happens something similar with systems that use the Identification document (DNI). There's a false assumption that these are unique and identify unequivocally one person. But that's not true. There could be more than one person with the same DNI. The additional overhead of using emails is what happens if users want to change the email. In any case, JWTs are agnostic to these concerns, they are just a container of data. – Laiv Sep 7 '17 at 6:58

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.

  • A customer wants to implement an SSO with JWT tokens for their legacy internal websites. Now, when a website receives a JWT, it has sub with ID that is unique in the context of the issuer and the website cannot find a user in its local database for the sub. We could send login username as sub, but some accounts don't have a username at all because they authenticate through Active Directory and have AD UIDs instead. So, we might send "username|AD_GUID" as sub to identify the user in website's local database by username or adguid. It looks dirty. I'm still looking for a clean solution. – JustAMartin Jul 31 '19 at 14:57
  • 1
    Add claims. Those you need, It will make things cleaner. You can send as many id as you need in diferent claims. Just make sure theres no claims' collision among systems – Laiv Jul 31 '19 at 17:58

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.