Microsoft identity platform consent framework
Multi-tenant applications allow sign-ins by user accounts from Azure AD tenants other than the tenant in which the app was initially registered. The Microsoft identity platform consent framework enables a tenant administrator or user in these other tenants to consent to (or deny) an application's request for permission to access their resources.
For example, perhaps a web application requires read-only access to a user's calendar in Microsoft 365. It's the identity platform's consent framework that enables the prompt asking the user to consent to the app's request for permission to read their calendar. If the user consents, the application is able to call the Microsoft Graph API on their behalf and get their calendar data.
Consent experience - an example
The following steps show you how the consent experience works for both the application developer and the user.
Assume you have a web client application that needs to request specific permissions to access a resource/API. You'll learn how to do this configuration in the next section, but essentially the Azure portal is used to declare permission requests at configuration time. Like other configuration settings, they become part of the application's Azure AD registration:
Consider that your application’s permissions have been updated, the application is running, and a user is about to use it for the first time. First, the application needs to obtain an authorization code from Azure AD’s
/authorizeendpoint. The authorization code can then be used to acquire a new access and refresh token.
If the user is not already authenticated, Azure AD's
/authorizeendpoint prompts the user to sign in.
After the user has signed in, Azure AD will determine if the user needs to be shown a consent page. This determination is based on whether the user (or their organization’s administrator) has already granted the application consent. If consent has not already been granted, Azure AD prompts the user for consent and displays the required permissions it needs to function. The set of permissions that are displayed in the consent dialog match the ones selected in the Delegated permissions in the Azure portal.
After the user grants consent, an authorization code is returned to your application, which is redeemed to acquire an access token and refresh token. For more information about this flow, see OAuth 2.0 authorization code flow.
As an administrator, you can also consent to an application's delegated permissions on behalf of all the users in your tenant. Administrative consent prevents the consent dialog from appearing for every user in the tenant, and can be done in the Azure portal by users with the administrator role. To learn which administrator roles can consent to delegated permissions, see Administrator role permissions in Azure AD.
To consent to an app's delegated permissions
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.
Submit and view feedback for