App Registrations in Azure AD

Question

i have some questions regarding adding permissions manually to app registrations

1. Im adding permissions to the app via the UX and click on save. After that these permissions are added to the requiredressourceaccess attribute right?

2. After that I click on “grant permissions” -> permissons are added to the service principal, right?

3. When checking the service principal after that I see the permissions are added via admin consent. Is this also possible with a user consent? Maybe im wrong here, and this is not needed but im wondering why the only option to do that is with a global admin which then results in an admin consent.

4. Also some permissions are stating that admin is not required.

   • This right can only applied via an global admin (or I did not find the right way via the ux) – but it says “requires admin NO”
   • After granting permissions, this right is also added via admin consent

5. If I just do step a and add permissions, click safe, permissions are added to requiredressourceacces

   • Does the user have to consent now to that permissions when accessing the app via. the my apps portal? I tried to repro, but it did not work.

Best Regards Thomas

Answer 1

Elisol has made clear about Grant permissions, This answer is just a supply to elisol's and reply to your 5rd quesiton:

If I just do step a and add permissions, click safe, permissions are added to requiredressourceacces. Does the user have to consent now to that permissions when accessing the app via. the my apps portal? I tried to repro, but it did not work.

For Azure AD v1 endpoint, the permissions is static. Once user has consented once it will not change. So,we have a Grant permissions for doing admin consent in advance. For your 5th questions , elisol has explained very well, but I want to make clear that the old user(who has done consent once) won't be promoted to consent. He/she should only have the permissions which consented before. If you want the user to have new permissions ,App should force the user to do re-consent by adding prompt=consent or prompt=admin_consent to the authorization URL.

If you want to specify the permissions your app needs dynamically, you can think to use AAD v2 endpoint. See here for difference between AAD v1 adn v2 enpoint.

I'm not sure what error message did you get( It's the reason I asked you post more details about your scenario). So, I list 2 situations you may came across.

1.If you came across that the user still needs to do consent after granting permissions from Azure portal:

As @junnas said, one reason may be that your App request contains prompt=consent or prompt=admin_consent to force re-consent. You can refer to his blog to try to fix it.

2.You cannot access to your App without enough permission(may have error massage with don't have access to this app).

First, ensure you have added enough permissions in Azure portal and granted permissions. Second, check if the resource in your request is correct WebAPP/API permissions. Third, Check if that have your define the App Roles and assign different role for the user (It calls Group based Access control).

Hope this helps.

Answer 2

Answering in order:

1. Yes, when you use the permissions UX in the app registrations blade, that adds the perms to the requiredresourceattribute on the application object.
2. Correct, clicking the "Grant Permissions" button runs consent in the background and adds the consent record to the service principal object in your directory related to this app object.
3. The "Grant Permissions" button tries to use the highest consent it can. If it's clicked by someone with a tenant admin role, it will do admin consent, otherwise it will do user consent (assuming there are no perms that require tenant admin).
4. Per the answer to #3, user consentable permissions don't require tenant admin, but if the Grant Permissions button is used by a tenant admin that will automatically do admin consent for all users in the directory. If you want to force user consent as an admin, today you’d have to hit the consent endpoint manually (such as by signing into the app before any consent has been granted).
5. Today, the consent system only checks whether any consent has been done or not for that user (or globally) when deciding whether to prompt the user automatically (so, for example, if you originally requested perms A and B, the user consented to A and B, and then you added perm C, the user would not automatically be re-prompted for consent but new users of the app would be prompted for consent of A, B, and C). Apps are responsible for detecting that a user hasn’t consented to an added permission and force a re-consent call.