This follows a recommendation from the OIDC specification stating that custom claim identifiers should be collision-resistant. While this is not mandatory according to the specification, Auth0 will always enforce namespacing when performing OIDC-conformant login flows, meaning that any custom claims without HTTP/HTTPS namespaces will be silently excluded from tokens.
Is this not a little over opinionated? The spec clearly states:
Alternatively, Private Claim Names can be safely used when naming conflicts are unlikely to arise, as described in the JWT specification.
I know that the claims our application will be using will not clash with anything else, yet Auth0 has enforced an optional part of a specification?!?
Sorry that you needed to wait for so long i just got the message from the team so here’s the reasoning.
This requirement exists to avoid collisions between claims that Auth0 may use and those used by our customers, we can’t sensibly rely on our customers to ensure that there are no collisions. What’s more, even if they have verified that there are no collisions at a given point in time that does not mean that Auth0 will not start using a new claim that might then cause a collision.
For this reason, Auth0 discards private claims and custom claims using the Auth0 domains.
It is also to prevent collision with any openid claims.
I understand the reasoning to avoid clashes, I think however that the method is a little off. We have a long domain name, and with the number of claims we need to append to tokens, this gets a little unwieldy to have to prefix all of them.
Would it not be better to educate about clashes, and allow them to occur having your claims override any values added by the users? That way it has been expressly explained that if it occurs, you take precedence.
We have our tokens set up to use claims of three characters to avoid brevity: uid, cid, aid, and we need to add more. To follow your implementation of the standard, I now have to prefix them as: https://thoughtriver.com/uid, https://thoughtriver.com/cid, https://thoughtriver.com/aid. This adds a lot of characters to the string, and means I now also have to add more code to parse these claims. I think it’s a little overkill to expect an https/https namespace prefix.
I would be happier (but still not fully) with a small prefix like a urn style like auth0: for Auth0 specific claims, and one for clients, as long as it contained : it could be understood as prefixed.
That’s not a questions directly to me but rather our product team I will certainly encourage you to relay that feedback along with all context to our product team directly using our feedback site:
One of the product managers will reach out to you shortly!
I will certainly encourage you to relay that feedback along with all context to our product team directly using our feedback site: