Fine grained authorization with OAuth2

Question

In my understanding of OAuth2 the scope may be used to specify access to what is asked and granted by code owner.

In most cases I encounters the scope list is closed and specify "kinds" of thing that can be accessed, for example profile, email, openid from Google Sign-in.

Does it make sense to encode access to specific resources in scope? Like account:{account number}:rw

This is for the case where user have multiple distinct resources managed by resource server and would like to authorize third party access to specific resources but instead of "kind" of resource. For example the hypothetical application would manage data folders and user U would grant read access to his folder "/A" but not any other folder to application B

I understand that in such case both Authorization and Resource server would have to parse and specifically handle such open ended scopes.

Are there other issues with that approach?

Is OAuth2 even right technology for such case? If not what to use instead?

Answer 1

I think the intent of OAuth scopes was to provide a framework for delegated consent, which is a form of discretionary authorization, but different from policy-driven authorization, which is what it sounds like you are trying to accomplish. The resource server has the responsibility to enforce both the delegation and the policy-driven approach. Scopes wind up being a like a claim, if you try to model policy-driven authorization and similar to role-based access control, will grow exponentially with the permission (action-resource) matrix (read-account, write-account, etc.) Your resource server developers have to know what each scope means to enforce: @PreAuthorize("#oauth2.hasScope(‘read-account’)") so you can see the complex if-then-else logic that can result.

Consider externalizing your policy decision from your Resource Server by having it use all of the context it has (id_token attributes, resource metadata, client footprint, scopes) to make a request of a policy decision service with "can [subject] do [action] on [resource] in this [context/env]?" The policy decision service is an domain that contains your risk, context and policy-driven rules like "External clients can read account details when the resource owner has a relationship with the account owner when 2-factor authentication is utilized." Look for services that support standards like JSON profile for XACML. This will keep you from running into scope explosion and help achieve more cohesive policies.

Answer 2

TL; DR;

This is a design flaw. Scopes represent the resource and in connection with your client (application) informs that this application has access to the resource. This level of granularity is not a good idea. In this case, you would end with a very hard to maintain list of, I would say, privileges for applications (not users). This is not how it should be done.

---

Scopes in their definition are rather the values which identify resources - not privileges. When you send a scope to the Authorization Server, by scopes you are informing what resources you want to access with your client (i.e. application) - not with your user. This is your Resource which should interpret if the user which is presenting the access token (with scopes) is legitimate to access it.

You asked about the scope in OAuth2 but please remember that OAuth2 is just a framework for AUTHORIZATION, rather not defined for authentication. For authentication of user you should use for example OpenIDConnect (OIDC) which is built upon OAuth2.

OIDC presents the identity token which is the carrier of user data. If you get the identity token and access token from authorization server your Resource would then decide if the particular user has access to the data he wants.