[Hydra] Permissions and scopes for selective groups/organizations/workspaces

[jannikkeye]

Hey there,

I've got a general question regarding scopes and permissions for Hydra Oauth2 flows. Imagine the following scenario

The application a client is requesting access for has lots of users. Each user can be owner or member of an group/organisation/workspace and each of those includes sub-resources that can be manipulated via an api. When the oauth2.0 client asks for permission to access the users data i.e. manipulate the sub-resources in the groups/orgs/workspaces of the user, the user should be able to select which groups/orgs/workspaces consent is given for. Groups/orgs/workspaces where the user doesn't have the rights for manipulation anyway would be omitted from the selection.

How would I reflect such a permission scheme in the oauth2.0 scopes? I'm sure I can make something like sub-resources:write sub-resources:read but that would include all sub-resources right?

Has anyone implemented something similar with Hydra? I would appreciate any help or pointers in the right direction.
Thank you very much.

[vinckr]

Hello @jannikkeye
You can probably implement something like this with OAuth2. But this is not the usecase for OAuth2.0 scopes. To quote directly from our docs:

The OAuth 2.0 Scope isn't an internal RBAC/ACL permission:

• A permission allows an actor to perform a certain action in a system: Bob is allowed to delete his own photos.
• OAuth 2.0 Scope implies that an end-user granted certain privileges to a client: Bob allowed the OAuth 2.0 Client to delete all users. But Bob might not be allowed to delete all users because Bob isn't an admin.
  The OAuth 2.0 Scope can be granted without the end-user actually having the right permissions. In the examples above, Bob granted an OAuth 2.0 Client the permission ("scope") to delete all users in his name. However, since Bob isn't an administrator, that permission ("access control") isn't actually granted to Bob. Therefore any request by the OAuth 2.0 Client that tries to delete users on behalf of Bob should fail.

If you want to implement something like RBAC I would recommend to look at the Ory Permissions/Keto project, also on github: https://github.com/ory/keto. This will save you a lot of time and lost hair over bending OAuth2 into something it is not designed to do.