Delegated Admin Extension rule/action namespace

Help
1

Hey there, I’ve been implementing the “Delegated Admin Extension” by following the docs here.

In the step “Add user roles to the DAE namespace in the ID Token using this rule”, I’m not using a rule but an action, and I don’t understand which namespace we should use for it.

My example is:

exports.onExecutePostLogin = async (event, api) => {
  if (event.client.client_id === '<CLIENT_ID>') {
    if (event.authorization) {
      const namespace = 'https://<TENANT_NAME>.eu12.webtask.io/auth0-delegated-admin';
      api.idToken.setCustomClaim(namespace, { roles: event.authorization.roles });
    }
  }
};

This above does not work because the namespace is somehow not accepted. I’ve checked this docs and it says:

  • Use any non-Auth0 HTTP or HTTPS URL as a namespace identifier. Auth0 domains cannot be used as namespace identifiers, and include:
  • auth0.com
  • webtask.io
  • webtask.run

I’ve noticed that if I put anything else as the namespace, it works, for example: https://something.com/auth0-delegated-admin.

What should be the correct value?

Thanks for the help!

3

Hi @serpa,

Thanks for reaching out to the Auth0 Community!

That’s is correct. Our documentation states that you will not be able to use a namespace that includes:

These namespace identifiers are reserved and prevent custom claims from conflicting with the list of standardized claims defined by the OIDC specification.

And, having looked closely at your namespace identifier, it appears that you used your Auth0 domain name as part of the URL. The correct value that you should set should look something similar to:

https://example.com/auth0-delegated-admin

Instead of using example.com, you can use your own uniquely defined namespace identifier in the URL.

Doing so will add user roles to the DAE namespace in the ID token.

Please let me know if there are any questions. I’d be happy to help.

Thank you.

1 Like
4

Hey @rueben.tiow, thanks for your response.

I’m still not sure what do you mean with:

Instead of using example.com , you can use your own uniquely defined namespace identifier in the URL.

What would be my uniquely defined namespace?
Shouldn’t the namespace be the target application URL?

From my experience, I thought the application only accepted a claim that is namespaced with its URL (or audience?). But I may be wrong, if you can point me to the correct understanding, I would be appreciated!

5

Hi @serpa,

In short, you need to use a URI as the namespace for custom claims. Note that using any arbitrary identifier can remove the custom claims from the token if there’s a conflict with the same namespace.

As stated in our docs:

  • Use a URL that you control as a namespace identifier; this allows you to avoid the risk that someone else is using the same namespace. The namespace URL does not have to point to an actual resource. It is only used as an identifier; it will not be called.

Therefore, your namespace should be in the format:

https://YOUR_APP.com/auth0-delegated-admin

6

Hey @rueben.tiow !

Thanks for your response.

I still don’t get it quite well.
It seems I can put anything I want in the namespace. What would forbid me to put https://google.com/auth0-delegated-admin?

Right now I have it working with a domain I don’t control which is:

https://example.com/auth0-delegated-admin

I understand that auth0 says I should use a domain I control, but what if I don’t? What happens? Can I interfere with someone who owns that domain? What if someone users serpa.com (let’s imagine this is my domain) for their namespace?

Thanks and I hope you can understand my doubts!

8

Previous message was deleted due to SPAM reasons.

9

Hi @serpa,

Thank you for your response and, I’m sorry for the delayed reply.

I understand your concerns and, thank you for asking these clarifying questions.

First, nothing is stopping you from using https://google.com/auth0-delegated-admin as your namespace.

However, let me clarify namespaces in more detail.

Generally, namespaces are invented names, typically using your registered domain to avoid possible collisions with standard OIDC claims.

Of course, it is possible for anyone to coincidentally invent and use the same namespace as you (i.e https://www.serpa.com/), however, this is typically not best practice and would run the risk of namespace collisions.

For example, if someone does decide to hijack a namespace, then they run the risk of breaking the interoperability between systems exchanging JWT for authorization.

As defined by the JWT specification, namespaces are required to be unique (collision-resistant) to prevent name collisions, including the reserved namespaces defined by Auth0, specifically, auth0.com, webtask.io, and webtask.run.

Hoped this helps! Please let me know if there are any questions.

Thank you.

1 Like
10

Hey @rueben.tiow !

I think I’ve understood!

Thanks a lot for clarifying it!

1 Like
11

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