Permissions, Privileges, and Scopes

Let’s break the question down into different levels.

At the OAuth level, scopes are just strings. The meaning of those strings is assigned by the user and the resource server. In other words, it’s up to you how to map a scope to a permission in practice.

Conceptually, a scope is what an application wants to do, while a role represents what a user/application can do. The goal of a scope is to restrict what an application can do on behalf of a user. For this reason they are mapped to the permissions a user can have: to have the most granularity in granting a permission. If I correctly understand, what you want to do is the opposite of what scopes were intended to do.
As far as I know, OAuth does not allow mapping between scopes and sets of permissions.

Accordingly, Auth0 allows you to define permissions in an API definition and implicitly map them to the corresponding scopes. This is a one-to-one mapping.

This does not prevent you from defining scopes that the resource server (and the user) interprets as a set of permissions. For example, you can create a scope and an associated read:all permission that the resource server interprets as permission to read any resource. Again, the final meaning of a permission is up to the user and the resource server.

In summary, you can’t define an explicit mapping between a scope and a set of permissions. You can define a scope that maps to a permission that the resource server can interpret as a combination of permissions.

1 Like