Why is Admin Consent required for permission

Question

I have a quick question surrounding permissions for an Azure Enterprise Application.

When adding the "Contacts.Read" permission to the application, the "Status" field is left blank. Admin consent is not required for this permission.

The permission also doesn't show up on the "Permissions page"

However, if i go back and click the "Grant admin consent for Default Directory", the status of the permission gets changed. The permission then shows up as expected, however its not under "User s-consent", its under "Admin consent", which makes sense since it was granted. My question is, why do i need to grant "Admin consent for default directory" for a permission that does not require it?

Answer 1

why do i need to grant "Admin consent for default directory" for a permission that does not require it?

Direct answer: you (generally) don't need to grant administrator consent for a permission; you simply have the option to do so.

Your implication is correct that permissions bearing the Admin consent required value of No don't... well... require Admin consent to successfully use... except, however, in (at least) two scenarios:

1. Your Entra ID configuration prohibits users from unilaterally consenting to the necessary permissions. This is a common (and oft-recommended) security configuration for organizations of any meaningful size to help combat the disclosure of internal data to unscrupulous 3rd party applications.

   When this configuration is set to something other than the default "Allow user consent for apps", even permissions listed in the views you've provided screenshots of will necessarily require some sort of pre-approval by a tenant administrator to use.

   You should also see the blue informational banner above the "Configured permissions" view that touches on exactly this:

   The "Admin consent required" column shows the default value for an organization. However, user consent can be customized per permission, user, or app. This column may not reflect the value in your organization, or in organizations where this app will be used.

2. Your Entra ID configuration allows users to consent to the necessary permissions, but you have a UX requirement for your application that disallows showing users the consent dialog. In more permissive environments, delegated permissions require users to explicitly allow your application access to the associated scopes on their behalf when first interacting with the application (or after the scopes your application requests change).

   By granting admin consent to a permission or permission set, you've essentially "pre-consented" on behalf of your users, so the permission request interstitial doesn't need to be shown on sign-in. From Entra ID's documentation page Overview of permissions and consent in the Microsoft identity platform:

   User consent

   User consent happens when a user attempts to sign into an application. The user provides their sign-in credentials, which are checked to determine if consent has already been granted. If no previous record of user or admin consent for the required permissions exists, the user is shown a consent prompt, and asked to grant the application the requested permissions. An admin may be required to grant consent on behalf of the user.

   The admin consent grant you're referring to does not override this interstitial being shown to users with accounts outside the directory for which you have administrative rights. For users from other Entra ID tenants, the administrator in that tenant would necessarily need to provide their tenant-wide consent to the permissions requested by your application to achieve the same effect. It's not possible to bypass this interstitial in the same way if you're using Entra ID authentication for non-enterprise users (i.e., Microsoft account authentication for publicly-accessible apps).