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!
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.
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’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.
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.