Design guidelines Auth0 RBAC API permissions for users and M2M clients

Get Help
,
1

In a B2B context with Auth0 RBAC for API’s you might want to limit the amount of permissions to keep the scope param in authorize request from bloating too much in user based login flows e.g. authorization code flow.

For example, a customer portal may need to request most of the API scopes, with the user’s actual permissions being determined then by their assigned roles.

On the other hand, M2M (machine-to-machine) clients should follow a least-privilege principle, using more fine-grained scopes to access only a limited set of APIs. In some cases, an M2M client might only need access to a single endpoint—one that could be even specific only to M2M client(s).

It’s also worth noting that we know scopes aren’t the only factor in API authorization for user-context flows. Those rely heavily also on user claims, so user-based scopes can be broader, while M2M scopes should be more restrictive.

Given this, you can technically define scopes as you wish, but I’d appreciate guidance on best practices for e.g. naming conventions and designing them effectively.

Would it make sense to use a hierarchical approach, such as:

Coarse grained scopes for users like:

  • projects:read - Access to view all projects information
  • projects:readwrite - Access to manage all projects information

More granular scopes for specific actions for M2M clients like:

  • projects:info:read - Access to only read project generic info

Or even

  • m2m:projects:info:read - Access to only read project generic info for M2M clients

Would a different API audience for m2m clients make sense?

3

Hi @mhautala

Welcome back to the Auth0 community!

I would recommend using coarse grained scopes whenever dealing with permissions, especially in the case of RBAC, or APIs permissions. However, using a more granular scope schema is not a bad choice if it fits better for your use case.

What do you mean by different audience for M2M clients? Do you mean that you are using a different API for RBAC then the one used for the M2M application?
If that is the case, you can split the “work” of your application to be handled by two different apis, one to handle RBAC specifically and another one for M2M communication. In this situation, I would understand why you would like to have very specific scopes such as m2m:projects:info:read but I believe it is for the best to use granular or coarse scopes.

If you have any other questions, feel free to let me know!

Kind Regards,
Nik

1 Like
4

Thanks for the comments.

What do you mean by different audience for M2M clients? Do you mean that you are using a different API for RBAC then the one used for the M2M application?

Yes exaclty. Though currently the M2M client use case is only a future plan and thinking this ahead on what is a good practice.

So sounds a separate API audience for M2M clients would not be a bad idea. In many cases it would make sense still to define specific route handlers for m2m clients with a different authorization logic (and then make the services and other layers reuasable).

5

Hi

So sounds a separate API audience for M2M clients would not be a bad idea. In many cases it would make sense still to define specific route handlers for m2m clients with a different authorization logic (and then make the services and other layers reuasable).

Yes, exactly! Make sure to not mix up the scopes or the audience in these scenarios! :wink:

If you need anything else, let m,e know!

Kind Regards,
Nik

1 Like