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. To identify the subject of the JWT, I currently have a claim which stores the user's email in the token. Does that pose a security problem? If so, should I be using a GUID or a hash of the email 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
  • 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. From the JWT security point of view, there should not be any problem, since email is an already valid public claim registered in the IANA.

On the other hand ...

I have a user db where each user's unique ID is their email ...

This make the question interesting because there's already 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.

Maybe, it would be more appropriated to use the claim sub instead of email because regardless of the format, the email is still an ID (in your system) and probably you want to treat the claim as such, rather than as an email.

Perhaps, nothing stops you from implementing both sub and email. That's application specific too.

Regardless of the claims, from the security standpoint, the main concerns are (or should be) to implement the TLS (https) and to sign/encrypt the token in order to reduce the attack surface fo the authorization process.

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.