Custom claims and namespaces

There are quite a few references to creating a claim without a namespace:

If I am reading this correctly there is no way to create a custom id_token to look whatever way you want with custom claims.
“iss”: “https://…”,
“sub”: “auth0|…”,
“aud”: “…”,
“iat”: 1572569202,
“exp”: 1572605202,
“roles”: [ “RoleA”, “RoleB” ]

The only way is to include a namespace with the “roles” so it would be “https://company/roles

Yes I understand it isn’t RFC spec creating Claims on the fly, but it would be great if I could do it.


You can request a feature here:

And we really do pay attention to customer feedback.

Asking for non-namespaced claims is going to be a tough sell, so please include details on why you need non-namespaced claims, the use case, the benefit etc.


1 Like

Thanks @john.gateley
My questions / concerns relate to:

  1. An id_token is supposed to be lightweight (thus small) as it is included as a Bearer token to authenticate to backend applications via the RP and used to enrich the customer experience. Having to always have a URI means you are expanding the payload by a minimum of 10 bytes for each custom value you want to add. More likely the key will be even longer to reflect the domain the host is using.
  2. I couldn’t find anywhere in the OIDC specification that says additional claims needed to be a URI.
    In the specification it recommends that additional claims are “collision resistant”.
    And then in references to RFC7519 for the JWT Format which is referenced in the OpenID Spec again there are vague statements about what collision resistant actually means.

Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.

But that doesn’t say it MUST include a domain name, only that it is RECOMMENDED.

  1. We were investigating moving from another IDP providers to Auth0 where that IDP allowed us to roll our own id_token with values such as “roles” and other custom claims. To avoid too much re-work we were hoping to keep the same id_token format and just update the authorize and token endpoints to now point to Auth0. But because Auth0 is inflexible with the namespace prefix for the custom claims code changes (albeit quite minor) is required in the applications consuming the IDP.

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