3 KiB
Permissions outside scopes
This was really interesting and this question about when to use or not scopes is generally a recurring one. So I should probably try to explain it more clearly. Perhaps I would need to write a doc, but if I try to make it easier to understand, maybe we can think about it this way.
Scopes are permissions that we can control via the OAuth2 clients. So when we put the permission inside scopes we gain:
- the ability to restrict the permission for some clients (for example we will be able to restrict DI access to some client without restricting access to Secure Client while the user can access both)
- checking for permission is easier because all permission are centralized in the scopes, always. This has consequences for the API as well as for the UIs but also for all external clients, so the permission can be enforced and published at the API level.
If we plan to have another set of permission outside the scopes, say, have a list of permission in another entity (like in the entitlement of the Org, or something related):
- In this case, the UI will need to check both the scopes and this new values. Knowing that the structure of such list of permission will be pretty similar to the structure of the scopes (mainly a list of string that represent permissions). The clients will not easily be able to know if they can access some resource or not.
- Internally, every API access permission only uses scopes, that would mean we will need to add another independent layer of checking that could cause confusion in the code, probably will have a non negligible impact on the performance of every API call (as we will need to check more than the scope, every API call will also need to perform addition call to the DB)
- We can no longer express that an OAuth2 Client is restricted to use some apps (like if we change the entitlement, we can no longer restrict that client not to use some app)
- With RBAC I see more and more concern about handling permission of external applications via IROH, so here too, it is easier to handle via scopes
- Every client (not just UI and IROH) will need to check two different set of permissions if they want to understand what is allowed to them or not. Mainly instead of just checking scopes, they will also need to check another permission system with potentially different access rules.
Everything about it is quite technical and not easy to convey in a discussion. But this is why I might need to write this down somewhere to explain the advantages and drawbacks of using another dimension for permissions. A good usage of not using scopes for some kind of permission are the audiences because this is not about the User's permission, but about the Client permission that still is granted to be used by some User.