Auth0 Home Blog Docs

Custom claims not added to access_token despite Rule

I see that you’re using an domain as the namespace for your custom claims. As stated in the documentation:, and are Auth0 domains and therefore cannot be used as a namespace identifier.

Any non-Auth0 HTTP or HTTPS URL can be
used as a namespace identifier, and
any number of namespaces can be used.
Given your tenant name, you can use something like var namespace = ''; as a valid namepace.


@ricardo.batista: I see that you’re using an domain as the namespace for your custom claims. As stated in the documentation:, and are Auth0 domains and therefore cannot be used as a namespace identifier.
Thank you. I changed my namespace to and, still, the data I am looking for is not included in the access token. Here’s the rule:

function (user, context, callback) {
var namespace = ‘’;
context.idToken[namespace + ‘user_metadata’] = user.user_metadata;
context.accessToken[namespace + ‘sms_userid’] = user.app_metadata.sms_userid;
//context.accessToken[namespace + ‘app_metadata’] = user.app_metadata;
//context.accessToken[namespace + ‘user_metadata’] = user.user_metadata;
callback(null, user, context);

But the access token payload looks exactly as before.

1 Like

Did you ever find a solution to this? I’m experiencing the same issue with my app, even though I followed the guide (SPA + API) to the letter. I’ve been struggling with this for the last day with no idea how to proceed. I’m using the live logging with logging statements in my rules and see that the custom claim has been added to the context.accessToken, but when I inspect the token it is missing the claims.


:wave: @tbutman are you still experiencing issues with custom claims? Could you maybe share your Rule here? And are you referring to this guide ?

1 Like

I have this Issue Kim, Please save my day

:wave: @pathmanshakir Rules are triggered once a user authenticates successfully. Is the user signing in first and then you are calling the userinfo endpoint?

1 Like

Hi @kimcodes,

Does it mean that when I perform a request to /oauth/token using Postman, the Rules are not triggered?


1 Like

Just to give you more context:

I’m peforming a POST request to /oauth/token via Postman with the following params:
client_id: {client_id}
client_secret: {client_secret}
audience: {api_audience} // get this on API > Settings > Identifier

Then I get the access_token and when I inspect using I only see the following info:

  "iss": ...
  "sub": ...
  "aud": ...
  "iat": ...
  "exp": ...
  "azp": ...
  "scope": ... 
  "gty": ...

But I do have a rule to add email and user_id to the access token:

function (user, context, callback) {
  const namespace = '';
  context.accessToken[namespace + 'email'] =;
  context.accessToken[namespace + 'user_id'] = user.user_id;
  callback(null, user, context);
1 Like

I have exactly this issue, my namespace is good, the rule is almost identical to yours, but nothing gets added to the access token. Did you manage to find a solution to this?


Hey, I have the same issue when using context.accessToken, but it seems to work when using context.idToken.

Still trying to find out what to do as well…


I’m also having an issue as I’m not able to add the custom claims to the access token. It would be interesting to hear if anyone has a solution to adding rules with custom claims to the /token endpoint with an example. I’m facing the same problem.

Looking around I found one discussion that suggested hooks like this instead for the token/ endpoint:
And: How do I get a rule to run when a client (not user) logs in?

And this discussion may implicitly suggest that indeed, it only works to add custom claims to id tokens with rules:

Can someone clarify if hooks are the solution and why? The explanation would help a lot of us.

1 Like

Hey, setting either the scope or a set of custom claims does not work for access tokens. I think I tried every single approach including the two from the rules samples:


I tested it both through the “try it” rule button, where the access token is augmented and when logging in and deciphering JWT.

@ricardo.batista could you take a look at it? I’m pinging you as you’re the Auth0 employee in this thread and maybe you have some way for testing it internally.

Cześć Szymon!

Recently we have some community developers reporting problems with running their rules. I’m not into the progress of things in that thread but you can find that one helpful:

Cześć :smile: Thx for chiming in. I’ll be watching the thread that you mentioned.

Keep on rockin’

1 Like

No worries thanks :slight_smile:

I’m having the same problem with context.accessToken, though does work with context.idToken. But just to double-check (and to help anyone searching at home) you need to include your custom claim URLs in your scope. For instance, if your rule is:

function (user, context, callback) {
  context.idToken[''] =;
  callback(null, user, context);

You would need to add the claim ( to your scope:

  auth0 = new auth0.WebAuth({
    domain: AUTH_CONFIG.domain,
    clientID: AUTH_CONFIG.clientId,
    redirectUri: AUTH_CONFIG.callbackUrl,
    responseType: 'token id_token',
    scope: 'openid name profile picture',

That is correct indeed!

For anyone else who ends up here - it appears that Rules are not run for Client Credentials Flow (used by M2M applications hitting the /oauth/token endpoint). According to an Auth0 support personnel:

Actually Client Credentials grant requests do not trigger Auth0 Rules pipeline because they are not considered user logins. They should be used only for Machine-to-Machine API calls.

In order to modify the Access Token scopes or add your own custom claims you can utilize the Client Credentials Exchange Hook:

Using Hooks resolved the problem for me, hopefully it helps others out as well.


Thanks a lot @owen for sharing it with the rest of community!

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