Auth0 Home Blog Docs

Role-Based Access Control (Roles & Permissions) [Product Roadmap: Launched]

roles
authorization
roadmap
rbac
roadmap-launched
#1

Role-Based Access Control authorization feature launched for all customers

When it comes to access control, Auth0 provides the “Auth0 Authorization extension” for implementing authorization policies. This extension, though fully featured, poses some limitations with regard to the number of groups and users due to limited webtask storage. To circumvent this issue, Auth0 is starting the process of moving the extension features into core platform features. The first step in this process is the introduction of RBAC.

With RBAC, access control is managed at a level that corresponds closely to the roles a user plays at the application level. Simply put, you can assign permissions to APIs based on the functional roles and then appropriately assign users to a role or a set of roles. With RBAC, access decisions to APIs are based on the individual roles users have in your application.

Key features of RBAC:

  • Create a systematic, repeatable assignment of permissions
  • Easily audit user privileges and correct identified issues
  • Quickly add and change roles, as well as implement them across APIs
  • Integrate third-party users by giving them predefined roles
  • Effectively comply with regulatory and statutory requirements

To learn more, you can find the documentation here: https://auth0.com/docs/authorization

Notes for Auth0 Authorization Extension users:

The Authorization extension will co-exist with the new RBAC and is completely independent. However, only one approach can be used for access control. To activate the RBAC settings in the core platform, you must stop using the Authorization Extension. Groups is not yet part of the new RBAC release so please keep this in mind before you decide to migrate.

What if I need groups?

If groups are needed, you can use the Auth0 Authorization extension. Note: You can only use one approach for access control: Either Authorization extension or RBAC. However, be aware of the restrictions with the number of groups that Auth0 can support with webtask storage.

For the new RBAC, groups are currently part of the roadmap. To stay tuned for our upcoming beta programs, please connect with us in the Auth0 community.

RBAC is a core platform feature and is available for all Auth0 customers and plans. To enable RBAC and begin using it, please follow the instructions here.

2 Likes
Do you need to use the Authorization Extension with the Core Authorization Library
#2

Are there any examples of an API usage for adding a role to a user? That has been a pain point for me, trying to figure out how to properly use the Auth0 API to programmatically add roles to a user.

It would be very helpful if there were some examples.

Thank you!

1 Like
#3

Hello @sikula,

Welcome to the Community! This might be what you are looking for:

3 Likes
#4

Is there any sort of migration process for the data in the Extension to RBAC?

#5

Currently we don’t have a migration guide published, but we’ll be putting one together for the official docs soon. If you need to migrate immediately and would like assistance, please create a new Community topic and we’ll be happy to help you through the process!

#6

Hello,
This feature is very welcome, but for stop using the Authorization extension (which has performance issues) and move forward to use this new feature, we need it to support groups.
Do you have any plans to support groups? if so, what are the timeline? when can I expect to see it in production?

#7

We will indeed be rolling out support for groups! We are not able to share any explicit timelines in the Product Roadmap category, but you can subscribe to the category to get updates as soon as we add roadmap announcements.

#8

The core RBAC functionality is great.

Just curious if there’s a recommended solution to assigning a default role to new users as they sign up? I can’t seem to find any documentation on this, and the role assignments don’t appear to be visible in the rules.

#9

Hey there everyone, we started a New Beta Program for Authorization Groups! Give it a look when you get a chance and be sure to let us know if you are interested in joining the beta program!

#10

I just want to add that for this all to work (for your access token to have the scope you expect) you need to add the scope parameter to your request (to /oauth/token) with the value being that of the API scope/permission you defined and added to the user/role. It took me quite a bit of testing to figure this out.

#11

Hi,

This is great for controlling access to my api, however how would i go about getting access to the permissions on the client such that my SPA can restrict routes and features based on the permissions?

Would i need to add the permissions to IDToken or is this a bad idea.

If that is the way to go, how do i access them in a rule to add to the ID Token.

Thanks in advance for your help.

Kind regards, Ed

#12

Hi @brotheredward! You can add permissions to the ID token as well as the access token using custom claims. Instructions for how to do this with a rule can be found here: Add User Roles to Tokens.

#13

Thanks @kim.maida , ah yes i can now see how to add the roles, and now appreciate API specific permissions are not necessarily what i need in the client. Would be great feature to be able to specify permissions against and Application (Client) in Auth0 such that features in my single page app could be enabled/disabled based on application permissions for the users role and changing the the permissions of a given role would not then required fiddling with my code but simply an update in the role-> permission mappings in the tenant.

This great post by Aditya Argawal extols the virtues of using permission based conditional logic over role based conditional logic in the client. (https://auth0.com/blog/role-based-access-control-rbac-and-react-apps/)

#14

Hey there, @brotheredward.

Kim is travelling to ngVikings where she will be speaking. As it would probably take sometime till she would be able to help you, I will jump in :slightly_smiling_face:

Have you seen the context object that is available on authentication transactions? This object contains information like clientID (the id of the Auth0 Application). I’m pretty sure that with some effort you can tailor an Auth0 Rule to your needs.