I have an API (resource server) configured, with a given set of scopes declared.
I have multiple 3rd party Clients configured that use the implicit grant autorisation call flow to get access_tokens on behalf of our users.
Each 3rd party Client has different rights over the resource server and should not be allowed the same inventory of scopes.
I’d like to make sure that a given client can only get access_tokens generated with a narrowed subset of scopes, for which it has autorisation for.
In other words the end-user, through the related 3rd party app, should NOT be able to request certain scopes that are not available for the 3rd party app developer, although they exists at the resource server level.
Obviously i could create a specific version of the resource server with only the authorized scopes and make sure the 3rd party developer targets the right API audience when authorizing the Client, but i’d prefer avoiding this.
Is there a good option to do that?
You can implement your own policy through rules and achieve your requirements related to scope restrictions for end-user based flows. For a (very basic) sample rule that does something similar you can check this other answer.
Have in mind that the linked sample rule assumes there’s only one API resource server configured and that every request is meant for API authorization to that API so you need to build upon that example for a more definitive solution that possibly checks if an access token is indeed going to be issued for a certain audience. However, the core logic required to restrict the issued scopes is fully demonstrated, but more based on the end-user rather than the actual client.
Given that your scenario the restrictions are imposed by the client application you should replace the end-user checks with client checks. You can also access client information from within a rule; see Context Argument Properties in Rules for more information on what data is available.
Excellent @jmangelo, thanks for your detailed answer, i’ll investigate this and let you know any further questions.
Excellent @jmangelo, thanks for your detailed answer, i’ll investigate this and let you know any further questions.