[QUESTION] AAD Consent screen should show merged permissions for middle tier Web API?

[luismanez]

Hi,

Apologies if is not the right place for this question, but I know some of the MS identity team members are active here.

I have a similar setup like here: https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/tree/master/2.%20Web%20API%20now%20calls%20Microsoft%20Graph#step-2-register-the-sample-application-with-your-azure-active-directory-tenant

In the sample doc, it says:

For a middle tier Web API (TodoListService(ms-identity-dotnet-native-aspnetcore-v2)) to be able to call a downstream Web API, the middle tier app needs to be granted the required permissions as well. However, since the middle tier cannot interact with the signed-in user, it needs to be explicitly bound to the client app in its Azure AD registration. This binding merges the permissions required by both the client and the middle tier Web API and presents it to the end user in a single consent dialog. The user then consent to this combined set of permissions. To achieve this, you need to add the Application Id of the client app, in the Manifest of the Web API in the knownClientApplications property

I´ve configured properly the knownClientApplications in the manifest, however, the AAD Consent screen, is only showing the Scopes that the middle tier web API is requesting, but not the Scopes that the client App request for the Middle tier web api. Adding some screenshots for clarification.

This is the middle tier web API exposing scopes:

Also, the API is requesting some permissions to MS Graph:

Now, the client App is requesting permissions to the middle tier web api:

The Client App Budgie_Client_Postman Id is configured in the API knownClientApplications . Also, I´ve configured both app to allow any AAD tenant (multi-tenant with no MS accounts)

However, the consent screen is only showing the permissions requested for the middle tier API (permissions to Graph), but not the permissions requested to the middle tier api (Budget.ReadWrite and Expense.ReadWrite)

Thing is that internally, all is working fine, cos I can see the proper permissions in both service principals:

But consent screen is not showing the merged requested permissions

Thanks!

[jmprieur]

@psignoret do you mind helping @luismanez ?

[psignoret]

@luismanez Currently, this is the expected behavior.

When Budgie_Services declares Budgie_Client_Postman as a known client application, and Budgie_Client_Postman has declared Budgie_Services as a required resource, it's similar to saying "this client and this resources are part of one application", so the resulting consent prompt omits the intermediate "connections" between what are effectively internal components of the solution.

I'll make an update the documentation on knownClientApplications and the combined consent prompt to make note of this.

I'm also interested to hear what you think of this behavior. It sounds like you expect (and possible want?) the specific permissions requested to a resource by a known client to be listed as well?

[luismanez]

Many thanks @jmprieur and @psignoret

I understand, and makes sense to me. I think the problem here is that the documentation makes you assume (or it did to me) that you will see ALL the permissions merged:

This binding merges the permissions required by both the client and the middle tier Web API and presents it to the end user in a single consent dialog.

If you update the docs with your comment, all is crystal clear.

I'm also interested to hear what you think of this behavior.

Well, I think it will help the end user to have all the requested permissions (intermediate and final). However, I don´t know how it will work if you have multiple apps like the scenario described here: https://joonasw.net/view/aad-api-chains-and-cyclic-dependencies (not sure how real-world is this XD)

Thanks again, you´re doing a great job with the Identity-Web library!

PS: will close the Issue as soon as you tell me.

[luismanez]

Closing this issue, as it was clarified by @psignoret (feel free to add any final thoughts if you want). thanks for your help @psignoret @jmprieur

[psoszynski]

Hi, I have read through the comments on this issue and am left with an impression that it has been closed without expressing what actions were in fact done to resolve the problems discussed here. Is it like the consent screen was going to be extended with permissions to the middle-tier api (as suggested by luismartinez) or the consent was going to remain as before, but the documentation was going to be corrected ?

[psignoret]

@psoszynski Reading back, the outcome was that the documentation was going to be updated.