Check custom claim in access_token

I have integrated auth0 OIDC service with 3 applications.
It was required that I use nickname as the preffered_username in those applications.

As per requirements I have added the custom claim, but I see errors in my application stating that claim nickname not found. Since I cannot use postman to fetch access_token, what should be my proper flow to check the access token claims.

If auth0 claim is perfect, then it might be my application that is fault, but I am unable to confirm whether auth0 is sending the claim in JWT.

Hi there @accounts.seclookup welcome to the community!

Are you able to get a hold of an example access token in one of your applications? You can decode it at

How are you adding the custom claim? If you’d like to share any extensibility code (Action, Rule, etc.) here I’d be happy to take a look.

Auth0 provides sample apps for all supported technologies so it may be worth configuring one to test with if you are unable to in your own applications.

Keep us posted!

Hello @tyf Thank you for your reply.

Are you able to get a hold of an example access token in one of your applications? You can decode it at

I am not able to get hold of the token in my application due to some reasons.

I have added Rules to add the custom claim to my token.
So, is there a way I can see what token auth0 sends to the application?

This is the rule if it helps

function addNicknameToAccessToken(user, context, callback) {
  // This rule adds the authenticated user's nickname to the access token.

  var namespace = '';

  context.accessToken[namespace + 'nickname'] = user.nickname;
  return callback(null, user, context);
1 Like

Thanks for getting back to me, and the rule code definitely helps!

I can confirm that the rule works as expected - I just tested this in my own environment.

You should be able to use the Resource Owner Password Flow to get an access token as long as that grant is enabled for your application. For example, I used a SPA app with the password grant type enabled (Application → Advanced Settings → Grant Types) and a curl request like the following:

curl --location --request POST 'https://{my_domain}' \
--header 'Content-Type: application/json' \
--data-raw '{
  "client_id": "5sFZ3AXXX",
  "username": "",
   "audience": "https://my-test-api-endpoint",
   "scope": "openid profile email",

This should return an access token you can inspect at - Like I said, your rule works as expected. Assuming you’ve switched that on in your tenant settings then my guess is this is breaking down elsewhere.

Keep us posted!

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