Managing App Registration Permission Consent

Go back to AZ-500 Tutorials

In this tutorial, we will learn and understand the basic concepts of consent, permission, and authorization models. However, applications that integrate with the Microsoft identity platforms follow an authorization model providing users and administrators control over how data can be accessed.

Scopes and permissions

The Microsoft identity platform is responsible for implementing the OAuth 2.0 authorization protocol. However, OAuth 2.0 is a method through which a third-party app can access web-hosted resources on behalf of a user. And, any web-hosted resource integrating with the Microsoft identity platform has a resource identifier, or Application ID URI. Some of Microsoft’s web-hosted resources include:

Microsoft Graph: https://graph.microsoft.com
Office 365 Mail API: https://outlook.office.com
Azure Key Vault: https://vault.azure.net

However, the same is true for any third-party resources that have integrated with the Microsoft identity platform. These resources can also define a set of permissions for dividing the functionality of that resource into smaller chunks. For example, Microsoft Graph define permissions to do the following tasks:

Firstly, Read a user’s calendar
Secondly, Write to a user’s calendar
Lastly, Send mail as a user

By explaining these types of permissions, the resource has control over its data and how API functionality is exposed. Moreover, a third-party app can request these permissions from users and administrators, who must approve the request before the app can access data. In this, the users and administrators can know what data the app has access to. And, developers should always follow the concept of least privilege, asking for only the permissions they need for their applications functioning.

In OAuth 2.0, these types of permissions scopes that also refers to permissions. However, permission is a string value in the Microsoft identity platform. Where the string value for each permission is:

Firstly, Read a user’s calendar by using Calendars.Read
Secondly, Write to a user’s calendar by using Calendars.ReadWrite
Lastly, Send mail as a user using by Mail.Send

Permission types

In Microsoft identity platform, there are two types of permissions delegated permissions and application permissions.

Delegated permissions:

They work with apps that have a sign-in user present. However, for these apps, either the user or an administrator consents to the permissions that the app requests. And, the app has assigned permission to act as the signed-in user while making calls to the target resource. You should know that, some delegated permissions can be consented to by non-administrative users, but some higher-privileged permissions require administrator consent.

Application permissions:

They work with apps running without a sign-in user present; for example, apps that run as background services or daemons. However, the application permissions can only be approved by an administrator.

Further, there are Effective permissions that refers to the permissions that your app will have when making requests to the target resource. Firstly, for delegated permissions, the effective permissions will be the least beneficial intersection of the assigned permissions the app has been granted (via consent). And, for application permissions, the effective permissions of your app will be the full level of privileges implied by the permission.

Requesting consent for an entire tenant

When an organization purchases a license or subscription for an application, the organization wants to set up the application for use by all members of the organization. However, as part of this process, an administrator can grant consent for the application to act on behalf of any user in the tenant. And, somehow if the admin grants consent for the entire tenant, then the organization’s users will not see a consent page for the application. For requesting consent for delegated permissions for all users in a tenant, your app can use the admin consent endpoint.

Admin-restricted permissions

In the Microsoft ecosystem, there are some high-privilege permissions that can be set admin-restriction. This include:

Firstly, read all user’s full profiles by using User.Read.All
Secondly, write data to an organization’s directory by using Directory.ReadWrite.All
Lastly, read all groups in an organization’s directory by using Groups.Read.All

However, if your app requires access to admin-restricted scopes for organizations, you should request them directly from a company administrator by using the admin consent endpoint. And, if the application is requesting high privilege delegated permissions and an administrator grants these permissions via the admin consent endpoint.

Lastly, if the application is requesting application permissions, and an administrator grants these permissions via the admin consent endpoint. Then, this grant is not done on behalf of any specific user.

Using the admin consent endpoint

When a Company Administrator uses your application for authorizing endpoints, then Microsoft identity platform will detect the user’s role. After that, it will ask them if they want to consent on behalf of the entire tenant for the requested permissions. However, there is an admin consent endpoint that you can use for proactively requesting that an administrator grants permission on behalf of the entire tenant.

Troubleshooting permissions and consent

Many applications integrating with Azure Active Directory require permissions for accessing other resources in order to function. And, when this resource integration is with Azure Active Directory, then permissions for accessing them is using the common consent framework.

However, some conditions must be true for a user for consenting to the permissions that the application requires. The errors below occur if these conditions do not meet:

Requesting not authorized permissions error

AADSTS90093: <clientAppDisplayName> is requesting one or more permissions that you are not authorized to grant.
AADSTS90094: <clientAppDisplayName> needs permission to access resources in your organization that only an admin can grant.

However, this error occurs when a user attempts to use an application that is requesting permissions that only an administrator can grant.

Policy prevents granting permissions error

AADSTS90093: An administrator of <tenantDisplayName> has set a policy that prevents you from granting <name of app> the permissions it is requesting. Contact an administrator of <tenantDisplayName>, who can grant permissions to this app on your behalf.

This error occurs when a company administrator turns off the ability for users to consent to applications. After that, a non-administrator user attempts to use an application that requires consent.

Resource not available in tenant error

AADSTS65005: <clientAppDisplayName> is requesting access to a resource <resourceAppDisplayName> that is not available in your organization <tenantDisplayName>.

Permissions mismatch error

AADSTS65005: The app requested consent for accessing resource <resourceAppDisplayName>. However, this request failed as it does not match how the app was pre-configured during app registration.