In our backend service, we have authenticated APIs that will perform some actions on a given entity. That entity E has different types of relations with a user (e.g. OWNER, REPRESENTER, etc). So, for example, user Alice might OWN entity E1 and REPRESENT E2, meanwhile user Bob might OWN E2.
We are trying to figure it out what is the best way to model the authorization checks for those entities, based on Auth0 roles and permissions and on those relations. Let’s say that both relations above would authorize the same action on the resource (e.g.
entity:manage). We can think of two approaches:
- We have a single permission
entity:manage, that both roles
REPRESENTERhave. When a user is authenticated, we check if it has the
entity:managepermission and, if yes, we check the set of all entities it has access, based on its role(s). If the user has role
OWNER, we take all entities with relation owned-by with that user. Similarly if the user has role
- We have specific permissions tailored for those relations, like:
OWNERwould have the former and a
REPRESENTERthe latter. So, upon authenticating an user, we can check the entities it has access to based solely on the permission(s) them have, not having to look for the role.
Right now, there is a high correlation between those specific permissions described on #2 and the roles that would have those permissions. We are still not sure if that would hold for the future, although we don’t have a use-case right now for different roles sharing those same, specific permissions.
Is there any obvious choice considering best design practices for such auth logic? Is there anything specifically bad in using the role at application level for narrowing the authorization of specific resources? Or, on the other hand, is there anything inherently wrong in having more specific permissions (that might, at some level, resemble the relation also being expressed in the role)?
Thanks a lot!