Custom claims and namespaces

[peter.lambrechtsen]

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

Custom claims without namespace

I’m trying to set up role based access with Auth0 and federated web identities on AWS (without Cognito). I have configured an OIDC provider, as described in the aws integration docs, and I have successfully attached custom claims to the id_token, namespaced, as enforced by Auth0. However, due to some limitations at AWS’ end, it is not possible to attach a trust policy to a role that are based on custom claims that are namespaced. So this does not work: AuthorizedAdminRole: Type: “AWS::IAM::R…

Custom claim without namespace

i have this role in my roles function (user, context, callback) { if(user.user_metadata){ const namespace = 'https://mywebsite.com/'; context.accessToken[namespace + 'role'] = user.user_metadata.role; context.idToken[namespace + 'role'] = user.user_metadata.role; } callback(null, user, context); } when i remove the name space it not work when i add it it work how to remove name space and make it work i need to get the role in the token

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://…au.auth0.com/”,
“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.

[john.gateley]

Hi,

You can request a feature here:

Auth0: Secure access for everyone. But not just anyone.

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.

John

[peter.lambrechtsen]

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”.
   Final: OpenID Connect Core 1.0 incorporating errata set 1
   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.
   RFC 7519 - JSON Web Token (JWT)

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.

3. 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.