1
votes

I'd like to define 2 different scopes for my API resource with IdentityServer4, similar to this: https://identityserver4.readthedocs.io/en/release/configuration/resources.html#defining-api-resources. There is 1 endpoint I want my client application to hit without requiring the user to login, and the rest of the endpoints would be fully protected with user interaction (hybrid flow fwiw).

I think I could get it working so either flow provides access to the API. What I'm confused about is with the configuration demonstrated above how do I limit the client credentials flow to only a limited scope? I don't want that flow to be able to hit the full extent of the API. Only once a user logs in would they get access to the rest...a different "scope" of the API...

This is for a native/mobile application, so the client secret for the client credentials will be embedded in the application. That is why the rest of the API needs to have better protection. But with the IdentityServer4 configured to allow both grant types for the resource wouldn't someone be able to discover that client secret and use it outside of the native application to gain access to the rest of the API anyway? How to limit that grant type to the more constrained scope...?

2

2 Answers

1
votes

You will need two different clients each with their own configuration to your resources (using scopes). The sub claim can be seen as user identifier claim, and thus has no place in the client credentials flow since it is a flow that is user-less.

0
votes

It looks like a partial answer, or an answer that "works" for my specific case, is found at the bottom of this page. A client credentials token will not have a "sub" claim, whereas a resource owner (and I assume hybrid etc.) will. So that can be used to differentiate the two when identifying permissions required for endpoints. I'm confused on the value of identifying multiple scopes in that case.