Difficulties in Adding Non-Restricted Claims to JWT Token

[ayden]

Hello everyone,

I’m having difficulty adding the email_verified to the JWT token through the use of the Authorization Code Flow from the Authentication API.

I’ve tried to add the email_verified to the token using the Flow but have been unsuccessful thus far.

exports.onExecutePostLogin = async (event, api) => {
  if (event.authorization) {
    api.idToken.setCustomClaim(`email_verified`, event.user.email_verified);
  }
};

I am having trouble with the code above since it’s not working as intended. However, I found that renaming the property email_verified to email_verified_abc made it function properly and display on the JWT Token.

Can you please guide me on how to display the email_verified property on the JWT Token?

[peter.fernandez]

Hi @ayden

There are a number of restrictions related to using non-namespaced custom claims in Auth0. This is to avoid accidental override of security/PII sensitive information, or situations where there could be a conflict with values set as part of the standard(s). You can read more information here.

Claims can also unintentionally provide bad actors with valuable information regarding PII, so often reading these via a non-browser based flows - such as via a direct call to the Auth0 /userinfo endpoint can be a more suitable solution. Particularly where such information is required by an API, say.

If you do have a specific need to set additional claims in either an ID Token or an Access Token then doing so via use of a namespacing is often the best way to go. FYI, email_verified is already a default claim set by Auth0 as part of a returned ID Token.

Hope this helps

[ayden]

Hello Peter,

Are you saying the ID Token can be obtained from /oauth/token?
If so, after obtaining and decoding the JWT token, I did not find the presence of the email_verified property.

[peter.fernandez]

@ayden

Are you saying the ID Token can be obtained from /oauth/token?
If so, after obtaining and decoding the JWT token, I did not find the presence of the email_verified property.

So the ID Token can be obtained in a variety of ways: if you’re using Authorization Code flow - the recommended option - with, or without, PKCE it is typically obtained from the Auth0 oath/token endpoint; if you’re using Implicit flow then it is typically returned via the browser.

To get the email_verified claim by default, the calling scope (see here for more details) should include email. This will also return the email address for the user, so if all you are wanting is email_verified then you will need to set this as a namespaced custom claim.

Hope this helps

[ayden]

I appreciate the help, Peter.

I will look into it. Thank you.

[konrad.sopala]

Let us know if you have any other questions related to that!