Add role to user via node-auth0 / Management API in Rule

Hey there –

I’m trying to implement role based access control, as described in this document: Sample Use Cases: Role-Based Access Control

What I’d like to do, is be able to have users who signup through portal X be automatically be given role Y. From my understanding I’ll want to use a Rule, and within that rule instantiate the ManagementClient. (alternatively I seemingly could use the app_metadata but that doesn’t seem as nicely segmented as RBAC, the difference between the two is nonetheless confusing) I then go to add this to my rule as per your documentation

const ManagementClient = require('auth0@2.9.1').ManagementClient;
const management = new ManagementClient({
  token: auth0.accessToken,
  domain: auth0.domain

I find the api management.assignRolesToUser does not exist (despite being available in your docs )

It appears the version of auth0 that the prior article suggested does not have that api. However I’m unable to pull in the latest version of auth0 into the rule (2.17.0), as per your docs the latest I can use for some reason is 2.13.0: Can I require? - Search which node modules you can use in

Reading through the raw source code for v2.9.1 and 2.13.0 (as there is no hosted documentation for older versions AFAIK), I am unable to determine how to assign a role to a user at signup. Please let me know. Slightly frustrating as this is unfortunately just one of a handful of different things that has taken me far more time to figure out with auth0 than I could have achieved just building it myself.


Hi @me_auth,

Welcome to the Auth0 Community!

There is a rule template that will get you 90% of the way there titled ‘set roles to a user’. Very similar to this. You will just have to write the conditional that runs the assign roles function when users are coming from the specific application. This method will not use the Management API, but is the most straightforward.

Does this help?


It appears that the example rule you linked here only adds the role to the users token, and updates their app_metadata with the role. It does not:

  • Assign them the role so as to be visible in the ‘Roles’ tab of the User Details.
  • Append the permissions associated with a given role to the user’s permissions

Is my understanding correct? If so does this mean that I will have to write another rule to append the permissions to the users token every time they log in?

As an aside, why is it that the documentation that you publish online, and the SDK you publish does not match the functionality available to developers in the Rules modules? Having to check the source of specific versions at node-auth0 every time I wish to use a function is very time consuming and non-intuitive.

What is the point of doing RBAC if all users get the same role?

If you do have a need for RBAC (i.e. there’s a potential for multiple roles to be granted), you can always make a direct call to the API from a rule instead of using node-auth0: See the NodeJS example in

You will need to get a new Management API token since I don’t think auth0.accessToken has the read:roles scope required per the documentation (that means even with a proper node-auth0 version you would still need to get a new token with read:roles).

Is there some way to assign a default set of permissions to new users? If not, wouldn’t I then be forced to use RBAC to assign all users the same initial role?

The idea behind roles and permissions is to grant different access levels to different users. If all users have the same role, then you don’t need roles, you just grant access based on the fact that the user is authenticated. If your application and/or API implementation require roles or permissions in the token, it will be much easier to assign on-the-fly through rules without having the overhead of assigning roles to users.

Even if there are multiple types of user access, if they can be determined by rules (opposed to being assigned by a human or process), it will be easier and safer to manage on-the-fly in Auth0 rules than through the Roles API. With the API there’s always a chance that a user will not get provisioned the appropriate role and will require some sort of remediation (automated or manual).

It comes down to:

  • will you have multiple roles?
  • will you have external processes controlling who has access to what (ex.: helpdesk or CRM)?

If you answered no to both, I don’t think you need to use the Auth0 Roles API.

My personal use case for the Role API is not what is being discussed here and distracts from the main point of the thread which is:

If I want to assign a role to a user, regardless of whether it is a single user or all users with email domains ending in ‘’, I cannot do that within the ‘Rule’ environment. The suggestion provided by the Auth0 staff is at best a work around for that, and at worst causes confusion by conflating the addition of a role claim in the users token to actually providing a user with the permissions contained in the Role as specified in the Auth0 dashboard.

I have managed this by just making HTTP requests from within my rule - not relying on the auth0 node client. You do need to get a new token that has the appropriate grants. See my responses in the other thread with some example code.

1 Like

Hi @a2hill,

I did a bit of digging on this and figured out the problem. The auth0 node client v2.9.1 does not support anything role-related, including the assignRolesToUser method you are referring to, it is only supported by the most recent version.

Given that version is only a couple weeks old, it has yet to be added to the modules available in Rules. This is all due to the fact that we are moving from the Authorization Extension to the Authorization Core, which will eventually provide a more flexible and integrated solution for RBAC.

With this being said, the strategy that @harmoN linked is going to be the most effective way to accomplish what you would like at the moment. I would be more than happy to help you through that solution if you have any questions.

We appreciate your patience while we make continual improvements to the platform.



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