'email' not in SPA JWT

Hi there, I’m following the React SPA quick-start, and then the Part 2 “Calling an API with an access token”. I’m using passwordless email auth.

It’s working fine, but the access token doesn’t contain the email address. It just contains:

{
  "iss": "https://_____.au.auth0.com/",
  "sub": "email|5ec4a________e5dda7",
  "aud": [
    "http://localhost:3001",
    "https://_______.au.auth0.com/userinfo"
  ],
  "iat": 1590041516,
  "exp": 1590127916,
  "azp": "1UYR________DFXb",
  "scope": "openid profile email"
}

I can get the email in the SPA, but I need a way to securely communicate that to the API. The sub claim seems to just have the auth0 ID for the user, but I need the actual email itself. I thought that adding ‘email’ to the scope would be sufficient.

Is anyone able to advise me on how to do this? Thank you!

1 Like

I found this discussion: Include user information in the access token: implicit grant flow

And it looks like I can add the email to the access token using a rule; but it feels like I’m not doing something right, since email is a basic claim.

Hi @will2, as that community post explains:

including OIDC standard claims as part of the scope parameter will only lead to the automatic inclusion of that information in the ID Token ; because that’s what the specification points to

The proper way to add it to the Access Token is to use a rule with a namespaced claim as shown here:

Alternatively, your API could call the /userinfo endpoint to get the user profile. Since the access token includes the scope openid email you will get the user’s email in the response:

Hi Ricardo, thanks for responding!

I’d rather not call /userinfo, because then my API response depends on a nested API response, increasing latency and introducing a new source of errors. What I like about verifying the JWT is that I can do it without any external calls.

It is very confusing that the access token is a subset of the id token; since in your bog-standard SPA+API crud app most of the important stuff is happening behind the API, so that’s where the user info is needed.

It seems like the correct thing is indeed what I’m doing, which is a namespaced claim implemented using a rule. It’s good that I have confirmation of this, and can proceed along this path. Thanks again for responding!