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?

2 Answers 2


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.

  • 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. Commented Oct 23, 2017 at 17:21


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.

  • I clarified the question - that I'm asking about granting application access to specific resources owned by specific users.
    – AGrzes
    Commented Oct 20, 2017 at 9:29
  • 1
    Still the same answer. As you wrote "multiple distinct resources MANAGED by RESOURCE SERVER". This would mean that you have a central resource which is able to manage access. This would mean that you can create scope for the resource server (i.e. folders) and in the resource server have a data store which maps the scope to particular users and specific folders. As an extension you can also think of granularity on the operations level: folder_read, folder_create, folder_delete, ... . Commented Oct 20, 2017 at 9:43
  • But if we are talking about "create(ing) scope for the resource server (i.e. folders)" then we have "dynamic scopes" as a set of resources can be changed at any time by user action. Then the question still stand if it is good idea or not?
    – AGrzes
    Commented Oct 20, 2017 at 9:52
  • No. Maybe I was not clear enough. I assumed that there is a central resource to manage the other resources. So every access to the other resources is gained through the central one. Commented Oct 20, 2017 at 10:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .