Consent experience for Azure Active Directory applications

Ganesh Chauhan, Technical Support Specialist, Microsoft Azure.

This article will teach you about the application consent user experience in Azure Active Directory (Azure AD). You will then be able to manage applications intelligently for your organisation and/or develop applications with a more seamless consent experience.

Consent is the process by which a user grants an application permission to access protected resources on their behalf. An administrator or user can be asked for permission to access their organization’s or individual’s data.

The actual user experience of granting consent will vary depending on the tenant policies, the user’s scope of authority (or role), and the type of permissions requested by the client application. This means that application developers and tenant administrators have some say over the consent process. To control the consent experience in their tenant, administrators can set and disable policies on a tenant or app. Application developers can specify which permissions are requested and whether users should be guided through the user consent flow or the admin consent flow.

User consent flow is when an application developer directs users to the authorization endpoint with the intent to record consent for only the current user.

Admin consent flow is when an application developer directs users to the admin consent endpoint with the intent to record consent for the entire tenant. To ensure the admin consent flow works properly, application developers must list all permissions in the RequiredResourceAccess property in the application manifest. For more info, see Application manifest.

Consent prompt building blocks –  The consent prompt is intended to provide users with sufficient information to determine whether or not they trust the client application to access protected resources on their behalf. Understanding the building blocks will assist users granting consent in making more informed decisions, as well as developers in creating better user experiences.

The app requires a permission that the user is authorised to grant.

In this consent scenario, the user accesses an app that requires a set of permissions that are within the scope of the user’s authority. The user is taken to the consent flow.

Administrators will notice an additional control on the traditional consent prompt that allows them to give consent on behalf of the entire tenant. The control will be set to off by default, and consent will be granted on behalf of the entire tenant only when admins explicitly check the box. The checkbox will only appear for the Global Admin role; Cloud Admin and App Admin will not see it.

Consent prompt for scenario 1a

Users will see the standard consent

Screenshot that shows the traditional consent prompt.

The app requires a permission that the user does not have.

In this consent scenario, the user accesses an app that requires at least one permission that is beyond the scope of the user’s authority.

On the traditional consent prompt, administrators will notice an additional control that allows them to consent on behalf of the entire tenant.

Consent prompt for scenario 1a

Non-admin users will be prevented from granting consent to the application and will be instructed to contact their administrator for access. Non-admin users can submit a request for admin approval from the consent prompt if the admin consent workflow is enabled in the user’s tenant. More information on the admin consent workflow can be found at Admin consent workflow.

Screenshot of the consent prompt telling the user to ask an admin for access to the app.

The user is taken to the admin consent flow.

The user navigates to or is directed to the admin consent flow in this consent scenario.

The admin consent prompt will be displayed to admin users. This prompt’s title and permission descriptions have been updated to emphasise that accepting this prompt will grant the app access to the requested data on behalf of the entire tenant.

Consent prompt for scenario 3a

Non-admin users will be prevented from granting consent to the application and will be instructed to contact their administrator for access.

Screenshot of the consent prompt telling the user to ask an admin for access to the app.

Admin permission via the Azure portal

In this scenario, an administrator agrees to all permissions requested by an application, which may include delegated permissions on behalf of all tenants’ users. The Administrator grants consent in the Azure portal via the API permissions page of the application registration.

Screenshot of explicit admin consent through the Azure portal.

 

Unless the application requires new permissions, no one in that tenant will see the consent dialogue. Administrator role permissions in Azure AD explains which administrator roles can consent to delegated permissions.

Note: – Granting explicit consent using the Grant permissions button is currently required for single-page applications (SPA) that use MSAL.js. Otherwise, the application fails when the access token is requested.

Common Issues

This section discusses common issues with the consent experience as well as troubleshooting tips.

403 error

  • Is this a delegated scenario? What are a user’s permissions?
  • Are the endpoint’s necessary permissions added?
  • Check the token to see if it contains the necessary claims to call the endpoint.
  • What permissions have been granted? Who agreed?

User is unable to consent

  • Check to see if your organization’s tenant admin has disabled user consent.
  • Confirm that the permissions you’re requesting are admin-restricted.

User is still blocked even after admin has consented

  • Check to see if static permissions are set to be a superset of dynamically requested permissions.
  • Check to see if the app requires user assignment.

 

For more information, contact Professional Labs, the Best Cloud Managed Services Provider GCC

Contact Us