Get user info from access token without access point /userinfo

I have a similar question to this (which was not answered AFAIK):

I have a SPA that connects to my API. After the user signs in using Auth0 on the SPA I now have an access token that I send along as an Authentication: Bearer header to my API. On the API end I define users by a unique ID, the unique ID is their email address. With every request to my API the SPA sends the access token and the email address of the user. I can trust that the profile information (including email) is okay on the SPA side of things (because the access token and profile information come from Auth0), but on the API end, I can’t assume that the email address sent is the one associated with the access token.

I can get the user profile information (including email) using the access token and the Auth0 API endpoint /userinfo. BUT, that is rate limited, so I can’t do that with every request to my API.

On my API I can look at the access token and see that it has information, an example of what I get is:
{“typ”:“JWT”,“alg”:“RS256”,“kid”:“QUE5NTg3RjA1BLAHBLAHBLAHAwREUwOUY1RERGMjA0REEyRDY2Ng”}
{“iss”:“https://{MY_DOMAIN}.auth0.com/”,“sub”:“auth0|5d82fba96575590dd1076725”,“aud”:[“https://{MY DOMAIN”,“https://{MY DOMAIN}auth0.com/userinfo"],“iat”:1569382570,“exp”:1569468970,“azp”:“yBLAHyAkssblahWbz4Vso9Hcbc7meiW”,“scope”:"openid email profile create:client_grants remove:authenticators read:authenticators enroll member:loggedin”,“gty”:“password”}

This doesn’t show the user email address.

I see that we can get user information from refresh_tokens:
https://auth0.com/docs/scopes/current/sample-use-cases#add-custom-claims-to-a-token

But getting a refresh token requires sending the code returned during the login process. I’ll need to store that in the database for each user and make a request to /userinfo again to get that information (running into the rate limiting problem again).

TLDR: how can I get the user info from an access token without using /userinfo. Perhaps adding the email attribute to the access token with a rule?

Hi @heath,

The example you liked with custom claims should be able to handle this. Take note of the namespacing rules when implementing this, as it can often cause confusion.

This will eliminate the recurring requests problem you mentioned.

Hope this helps!

Thanks,
Dan

Hi, @dan.woda.

Thank you for the quick response. Your suggestion worked. I had tried this before but without the ‘namespacing’. Here is my rule for anyone who comes after looking for the same solution:

function (user, context, callback) {
  const nameSpace = 'https://mywebsite.com';
  context.accessToken[nameSpace + ' email'] = user.email;
  
  callback(null, user, context);
} 

For the record the docs here say:

“For this profile, Auth0 would normally return the following ID Token claims to your application:”
{
“iss”: “https://my-domain.auth0.com/”,
“sub”: “custom|123”,
“aud”: “my_client_id”,
“exp”: 1311281970,
“iat”: 1311280970,
“email”: “jane@example.com”,
“email_verified”: true
}

But I don’t get the ‘email’ or ‘email_verified’ fields.

Thanks

1 Like

To clarify, this is in reference to the ID token, not to be confused with the access token.

Are you not receiving the requested info in the ID token?

Thanks,
Dan

I see where my confusion is now. I do not have access to the ID token on the API, only the Access Token which is sent in the Authorization header from the SPA.

I do not want to request user information on each request because of the /userinfo endpoint being rate limited.

I have gotten what I need by adding info to the access token via custom claims by using a rule as noted above.

I realise now that I can do without the rule and send the id token along with the access token to the api. The information is in the id token as suggested by the article I linked above.

Hi @heath,

Sending the email with the request is a solution too. It is going to depend on how you want to handle it. Glad you are thinking about different solutions and thank you for sharing them with the community.

Best,
Dan

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.