Is it a good idea to abstract away the concept of a "permission", decoupling it from scopes and roles?

[julealgon]

I'm currently working on a REST API where I want to have fine-grained control of many different reads and writes to a few resources/routes. At the same time, I also want the API to be accessible both by actual users in our organization, as well as other applications/background processes/daemons.

I learned recently that scopes only make sense for user access, and that for applications, I should be using "app roles". I initially believed I could solely use scopes for representing permissions in a unified manner, so this realization came as a shock to me.

However, trying to handle them both as different types of access on my API leads to quite a bit of code and honestly, I think that these concepts are very low level to expose to someone reading the API code (the fact that scopes and roles can work differently depending on the token type).

So, I contemplated abstracting all of this away into my own concept of "permissions". Instead of explicitly authorizing scopes or roles in any given method, I'd authorize "permissions", and then I'd perform either a scope or a role check in the background depending on the type of the token being passed to the API. With requirements and requirement handlers, I could do this by:

1. Defining a service/class/helper that maps from a "permission" to a "scope" or "role"
2. Defining my own custom PermissionsRequirement that stores which permissions are needed for any given action (say, "Reservations.Read" for reservation resources)
3. Registering a UserPermissionsAuthorizationHandler, that would check whether the current token is a "user token" and, if it is, check whether it has the required scopes related to the permissions I passed by consulting the "permission" -> "scope" service map
4. Similarly to the above, registering a ApplicationPermissionsAuthorizationHandler, that would check whether the current token is a "application token" and, if it is, check whether it has the required roles related to the permissions I passed by consulting the "permission" -> "roles" service map

Since 3 and 4 are handlers for the same requirement, they would naturally work as an OR between the 2 scenarios:

• an user is trying to access -> check the correct scope(s) -> succeed if permission-to-scope mapping exists and the scope is present
• an application is trying to access -> check the correct role(s) -> succeed if permission-to-role mapping exists and the role is present

This would provide me with a more centralized means of specifying whether or not any given action is available to users, to applications, or to both, and control them in a more abstract manner.

While I strongly feel this would be much cleaner than trying to shoehorn the existing scopes and roles checks manually somewhere (say, calling HttpContext.ValidateAppRole and HttpContext.VerifyUserHasAnyAcceptedScope like this). I fear I might be "reinventing some wheel" here by creating this whole abstraction and that perhaps there is a simpler, more standard way to go about this.

Do you think is is a sound idea to abstract away this concept of "permissions" in my implementation so I can handle both users with scopes and applications with roles in the same manner, or would you recommend a different approach that keeps the more explicit scope and role checks evident? Is there some existing mechanism that I'm missing that I could leverage to achieve the same results in a more streamlined way? Lastly, would it be advisable to name scopes and roles similarly/identically at all, or should I keep those names different on purpose?

Related:

• Add extension method on 'ClaimsPrincipal' for checking if it is an "app-only" principal/token #1684
• .NET 5.0 protected web API - verify scopes or app roles in a single action #1302
• Why does '[RequireScope]' check non-user token scopes? #1683
• [Documentation] How to verify scope or app role in the same controller action #963