Multiple ApiResource's sharing scame scope name errors

[DotNetRockStar]

If I have multiple ApiResource's. Can those resources share the same scope name? Right now the framework is suggesting that it cannot. I am getting the following:

Unhandled exception: Duplicate API scopes found. This is an invalid configuration. Use different names for API scopes. Scopes found: stuff
System.Exception: Duplicate API scopes found. This is an invalid configuration. Use different names for API scopes. Scopes found: stuff

When I ask for a token:

client_id={{clientId}}&client_secret={{clientSecret}}&grant_type=client_credentials&redirect_uri={{redirectUri}}&scope=stuff

With the following ApiResource's (serialized):

[
   {
      "ApiSecrets":[

      ],
      "Scopes":[
         {
            "Name":"blah",
            "DisplayName":"",
            "Description":"",
            "Required":false,
            "Emphasize":false,
            "ShowInDiscoveryDocument":true,
            "UserClaims":[

            ]
         },
         {
            "Name":"stuff",
            "DisplayName":"",
            "Description":"",
            "Required":false,
            "Emphasize":false,
            "ShowInDiscoveryDocument":true,
            "UserClaims":[

            ]
         }
      ],
      "Enabled":true,
      "Name":"SomeApi",
      "DisplayName":"SomeApi",
      "Description":"SomeApi",
      "UserClaims":[

      ]
   },
   {
      "ApiSecrets":[

      ],
      "Scopes":[
         {
            "Name":"stuff",
            "DisplayName":"",
            "Description":"",
            "Required":false,
            "Emphasize":false,
            "ShowInDiscoveryDocument":true,
            "UserClaims":[

            ]
         },
         {
            "Name":"things",
            "DisplayName":"",
            "Description":"",
            "Required":false,
            "Emphasize":false,
            "ShowInDiscoveryDocument":true,
            "UserClaims":[

            ]
         }
      ],
      "Enabled":true,
      "Name":"SomeApi2",
      "DisplayName":"SomeApi2",
      "Description":"SomeApi2",
      "UserClaims":[

      ]
   }
]

being returned by the following method on class extending IResourceStore interface:

public async Task<IEnumerable<ApiResource>> FindApiResourcesByScopeAsync(IEnumerable<string> scopeNames)
{
 ...  returning the two ApiResource's shown above
}

[brockallen]

If I have multiple ApiResource's. Can those resources share the same scope name? Right now the framework is suggesting that it cannot.

Correct, this is how it's designed and is a trade off to allow other features.

[DotNetRockStar]

If you don't mind me asking, what are the other features that it enables? I know that I am going to get asked why we can't share scopes across applications so if I have an answer that will help answer it when asked. Thanks.

[brockallen]

From a design perspective scopes are meant to model your API. Why do two different APIs have the same scope?

Introspection becomes odd when two different APIs share the same scope, and that's why it's designed the way it is now. In IdentityServer3 all scopes were "flat".

[DotNetRockStar]

Sure, scopes are meant to model the api auth. If the API wants to have a scope of "admin", for example, why should another api not be able to use the scope "admin"? Are you suggesting that every ApiResource needs to know about every other ApiResource's scopes in order to not create a duplicate scope? In the scenario where someone wants to register their API with the identity server, now they have to cross their fingers that the scope they want, and perhaps coded for, is not being used by some other API in the system. Why should the system care what an API calls its scopes or if the scopes overlap?

Consider this problem when you are hosting tens, if not hundreds, of APIs in an enterprise setting using this system, like I am about to do. There are going to be common scopes that everyone is going to want to use for their APIs. However, they are not going to be able to do that. Off the top of my head here are some that I have already been asked about:

• email
• admin
• super admin
• developer
• profile
• qa
• general user
• security admin

Now when someone goes to register their API against the identity system, they may (or may not) be able to create the scopes that they want for their API because "another api is using that scope". Why do/should they care that another API is using that scope? Why should they have to come up with some unique scope name? Now throw 50 APIs in to the mix. cringe
Sure you could "prefix" your scope with your "ApiResource" name, or something like that, but why should you have to do that?

Perhaps there is a scenario that I am not thinking of? If I forked the code and removed this constraint would it break anything within the system that you know about?

Thanks!

[brockallen]

Yes, scopes need to be unique across all APIs. Imagine if they were not -- a client's request would be ambiguous. Look at how google does it: https://developers.google.com/oauthplayground/. Normally I put a dot in mine if I want to have multiple scopes per logical API, e.g. "mycoolapi.read-only", and "mycoolapi.read-write".

[DotNetRockStar]

Cool. I'll come up with a naming convention for the team. Thanks for the reply.

[brockallen]

Also, beware creating too many scopes. Scopes are meant to allow an end user to give permission to a client application to use the API on the uer's behalf. They're not meant for user-level permissions (the sound of some of your scopes above worry me, like "qa" and "general user"). I've seen train wrecks where people misunderstand and/or overuse scopes. Just something to consider.

[james-world]

@brockallen Interesting comments. We are developing a typical SOA architecture with multiple autonomous (independent) APIs composed at the UI layer.

A UI application will require access to multiple APIs. It will typically need to access most of the APIs servicing the needs of multiple users. The UI itself is a resource that users access. But it is itself a single client of the multiple backend APIs.

Because in IdentityServer, scopes are "scoped" to a resource, this means that either the UI must make a single request to IdentityServer asking for many scopes, or the UI must manage multiple tokens for each service it needs to access.

What I was hoping for, was that by adding the same scope to multiple resources, requesting that single scope would grant a token with an audience for all the API resources that shared that scope. This model is unambiguous since the scopes are shared - you don't have to disambiguate between resources - you are asking for accessing to all of them by specifying a single scope.

Clearly, we can just ask for multiple scopes - but as it is currently, this model does run the risk of "too many scopes" being created since we have to create at least one scope per resource.

I wondered if you had any thoughts on this?

[brockallen]

Because in IdentityServer, scopes are "scoped" to a resource, this means that either the UI must make a single request to IdentityServer asking for many scopes,

You can request multiple scopes in one authorization request, and the resultant access token can be used at those different APIs.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.