28

I'm new to authentication, and just trying out JWT authentication on a small express app.

I've got a user authentication setup using JWTs, and I'm using the subject as the user's email.

Is this a good practice?

If I decode the JWT on jwt.io, I see:

{
  "sub": "test_user_3@test.com",
  "iat": 1489963760,
  "exp": 1490568560
}

Is that how it is supposed to work?

user1354934
  • 8,139
  • 15
  • 50
  • 80
  • For a 'normal' website yes - looking at the definition of 'principal' on Wikipedia helped me understand this more you have to remember that these tokens can be used by something other than a person with an email. `Principals can be individual people, computers, services, computational entities such as processes and threads, or any group of such things.` So whatever makes most sense to be unique in the context of your system. – Simon_Weaver Jan 28 '19 at 20:24
  • Watch out though if you allow a user to change their email address that you give them a new token at the same time - or they're instantly locked out :) – Simon_Weaver Jan 28 '19 at 21:41

1 Answers1

31

The sub claim must be unique. Since email addresses are unique, it is a reasonable choice for the claim.

See RFC7519

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.

Ensure two users do not register theirselves with the same email address, for example using a generic email like info@test.com

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • THanks. But is it fine to have it like that? If someone gets that JWT they can find out the user's email. – user1354934 Mar 20 '17 at 20:18
  • 1
    If someone gets a JWT, then you have a problem because he/she can impersonate the user in your API. You must protect it: Use https and secure storage. Including a claim in the JWT does not mean that everybody has access to it. About your question, you need to think if the email or other claims can be considered sensitive data in the context of your system. In this case be careful with them, or do not include them in the token. For example you could use a random user ID instead of email – pedrofb Mar 20 '17 at 20:35
  • Thanks. That's very helpful. I don't want to bother you too much but do you mind giving more info on the protecting API part, or if you know any good articles. Now I have a new worry that someone will get the JWT and start messing around with my API as if they are a user/client! – user1354934 Mar 20 '17 at 21:11
  • For example, someone could just open up postman interceptor and start fiddling around. THanks – user1354934 Mar 20 '17 at 21:12
  • 1
    Publish your API endpoint only with SSL/TLS (https). The communication channel between client and server will be encrypted, so nobody sniffing the network could see the content. – pedrofb Mar 20 '17 at 21:34
  • Thanks. But if the client was malicious person and decided to take the JWT I send back from session storage, then he can do much harm right? Just want to make sure. – user1354934 Mar 20 '17 at 22:14
  • Yes, possesion of JWT is the proof-of-authentication. A user could use the token to invoke your server – pedrofb Mar 21 '17 at 08:02