I’m using a rule to include a custom namespaced claim (e.g. https://example.com/claim
) in the idToken
, per the guidelines here: Create Custom Claims. This works great; when I test out my login flow I see "https://example.com/claim": "value"
in the resulting profile data.
However, I’m trying to connect to this first Auth0 tenant from another tenant, using an enterprise OIDC connection. When I do so, it looks like Auth0 renames my custom claim to https://example:com/claim
in the resulting user profile (replaces the dot/period with a colon). Why does this happen? I spent several hours debugging my setup only to realize that Auth0 was replacing that character, and I have not been able to find any documentation warning about this. https://example:com/claim
is not a valid URI.
I wonder if this has something to do with why properties with .
characters are not allowed in app_metadata
or user_metadata
? Could that restriction be relaxed? Property names that include .
are very likely if you follow the recommendations of using a domain name as a namespace.
1 Like
Hi Blake,
You are right, the dot/period .
is not allowed in user profile’s field names, not just in app_metadata
or user_metadata
.
If you try to update the user profile with the following payload it will fail with error Fields with \".\" are not allowed, please remove all dotted fields. Example: user_metadata.foo.bar
{
"user_metadata": {
"foo.bar" : 12345
}
}
However, if the user profile is from an external IdP, such as an OIDC connection in your case, we cannot control the field names of the user profile from the IdP, and it’s not worth to reject the authentication just because we don’t like the dot in the IdP’s user profile. So we replace them with colon :
.
As a workaround, you could the following regex in a rule in the 2nd tenant to replace the colon in the field names back to dot:
// change the colon back to dot in the namespaced URL
let new_claim = claim.replace(/(?<!(http|https)):/g, '.');
2 Likes
Thanks for helping with this one @Guangjie !
Thanks @Guangjie. I’m glad to know that this a known limitation / workaround in the system.
Given that Auth0 requires custom claims to use a URL-like namespace which will almost certainly include a .
character, this feels like something worth mentioning in the official documentation somewhere.
2 Likes
Thanks for sharing that feedback I’ll relay it to our docs team!