Custom claims in access token no longer appearing

I have a collection of SPA sites that pass the JWT to the ASP Web API backend, which verifies the token is valid and extracts some custom claims I’m inserting (using a rule) for permissions.

Sometime in the last few days my API has started complaining the users aren’t authorised. Long story short it looks like the access token no longer contains the custom claims. The API is validating the token OK but without the custom claims the [Authorize(Roles = )] attribute I’m using is rejecting the user.

I’d like to stress that in this time I’ve made no code changes so why this is suddenly happening after working perfectly for quite some time I have no idea. Any help greatly appreciated!

Hi @olly,

Welcome to the Community!

Can you DM me the name of the effected tenant?


I am not seeing other users reporting this same issue, so it is unlikely to be a widespread issue. Let’s do some debugging in your tenant and then I will try to recreate the issue.

Did you recently change the configuration variables in rules? Is it correctly namespaced?

Can you add a console log to confirm that the rule is being run, and the condition is being met?

Let me know if those are true and we can go from there.


I added debugging to the rule before creating this post and I could see my console logging appearing in the log viewer, so the rule was running OK.
The namespace for each tenant is its full domain with the periods replaced with colons, which had worked fine for the last few months. I had read that article you posted (again before I created this post) and tried using a custom url instead but it still didn’t work.
I had also tried decoding my access token and checking the payload, which was missing the custom claims section entirely.

As of this morning, however, everything is working again! I was testing using a different custom namespace on one tenant, which worked fine and was giving me the custom claims in the access token payload. I then tried the other tenants (which I have made no changes to) and the custom claims section appears in my access tokens again, using the same old namespace we’ve used for months.

It seems like it might be better practice for us to use a correctly-structured url instead of our tenant’s domain with colons instead of periods, so I will change that, but it still was and is working using our current namespace.

Any insight into what’s happened would be appreciated.

Many thanks,

Also have just seen this: Rule with blank namespace stopped working for two days then started working again so it’s not just me who has experienced this problem.


Thanks for following up. I’ll check in with the team to see if there was a change that would cause this.

The namespacing in the post you linked is not recommended and I would not follow that pattern. They should not be using that unless they have a legacy tenant (which is possible).

By default, Auth0 always enforces namespacing; any custom claims with non-namespaced identifiers will be silently excluded from tokens.

We do allow non-OIDC claims without a namespace for legacy tenants using a non-OIDC-conformant pipeline with the Legacy User Profile enabled, but we strongly recommend that legacy tenants migrate to an OIDC-conformant flow.

I reply here with my findings.

Hi @olly,

I’ve heard back from the team. There was an issue where certain custom claims that were invalid URLs were not being added to the token.

This is issue was identified on the 15th and should have been resolved within 24 hours. It sounds like that would be within the timeline you have stated. Let me know if anything doesn’t match that description and I will update the team.

Thanks for your patience,

Hi @dan.woda,

that sounds exactly like what we experienced. Thanks for getting back to me. We originally started using Auth0 around 2.5 years ago and were using that pattern for namespaces back then, so I guess it’s something we’ve carried over but shouldn’t have! Thanks again for your help.


Thanks for following up with us! Let us know if you run in to anything else.

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