OpenID Connect with user bound roles and M2M access

Question

I'm trying to get my head straight about how to properly design a OpenID connect provider and the roles to use with it. I understand the basic of scopes, claims and the different flow one can use. However, I'm trying to get my head around how I should handle the cases where i want M2M access to all resources, and a end user should only have access to his/her data.

My question is more related to how I should handle roles, is it overkill to have roles such as:

• view_company_data
• view_all_data

An example could be to provide a public API to access all data, e.g. collaborating companies, while also allowing me to have specific users to only access the data created by him/her. In my case that would be government body that wants access to all data, whilst the business owners should only have access to their own data.

I have an authentication provider, along with several resource servers. The business owners access their data through our client with only read/write permission for their own entity, and the government body wants access through our APIs to access all the data.

I wish to have all access control in a central entity, so generating access tokens on each separate resource server along with default JWT tokens from the authentication server seems like a bad idea. I'd rather handle it all from the authentication server.

Also a user should be able to generate these full-access tokens, given that they have an Global administration role.

So, what would be the right thing to do here?

Answer 1

OpenId connect is used to provide an authorization framework. Specific permissions are out of the scope of Oidc. Your problem is strictly a permission problem, and there isn't any absolute rule provided by oidc for that.

Of course, everybody is using the scopes to solve that, when required, but basically it really depends on your overall architecture and requirements. Basically there's 3 philosophies here:

1. The Oidc IP will only be used to define which user has access to which ressource (RP), with very limited access. The permission logic will be handled at each RP level. It usually means that on the first login, the user is cloned in the RP with no access and an admin grant him specific permissions when needed. Admin of the IP is simple because you only have to say user X has access to app Y, but admin of each app can be painful.
2. The Oidc IP will be used to handle permissions using scopes/roles. The permission logic is thus completely handled at the IP level. Hopefully the IP will provide realms logic to handle this otherwise it will become a nightmare.
3. A mixed logic, for example, in your use case the type of user (business or government) could be stored int he IP and provide basic permission for each type of user on creation. That means that permission is still handled by each RP, but, when the user is cloned, specific permissions are granted on creation depending on the type of user. More flexible, but rules on what permissions are handled at the IP level and what permissions are handled at the RP level should be very cleared defined, otherwise you'll most likely have a ton of problems, and potential vulnerabilities.

In my company we choose the third solution. Basically the IP always provide the user type (normal, admin, superuser) for each user/RP, and the user is created with limited rights (except for superuser) in the RP. Then we can fine tune the user permissions in the RP admin when needed. We also get have a "company" scope allowing us to link the user to its company and define its permissions depending on the company. On each connection we also check if the user type should be updated. Of course we use nonce/state and pkce flow with a private key signed token.