Manage consent to applications and evaluate consent requests
Microsoft recommends that you restrict user consent to allow users to consent only for apps from verified publishers, and only for permissions that you select. For apps that don't meet these criteria, the decision-making process will be centralized with your organization's security and identity administrator team.
After you've disabled or restricted user consent, you have several important steps to take to help keep your organization secure as you continue to allow business-critical applications to be used. These steps are crucial to minimize impact on your organization's support team and IT administrators, and to help prevent the use of unmanaged accounts in third-party applications.
Process changes and education
Consider enabling the admin consent workflow to allow users to request administrator approval directly from the consent screen.
Review your organization's existing processes for users to request administrator approval for an application, and update them if necessary. If processes are changed:
- Update the relevant documentation, monitoring, automation, and so on.
- Communicate process changes to all affected users, developers, support teams, and IT administrators.
Auditing and monitoring
Audit apps and granted permissions in your organization to ensure that no unwarranted or suspicious applications have previously been granted access to data.
Review the Detect and Remediate Illicit Consent Grants in Office 365 article for more best practices and safeguards against suspicious applications that request OAuth consent.
If your organization has the appropriate license, do the following:
- Use other OAuth application auditing features in Microsoft Defender for Cloud Apps.
- Use Azure Monitor Workbooks to monitor permissions and consent-related activity. The Consent Insights workbook provides a view of apps by number of failed consent requests. This information can help you prioritize applications for administrators to review and decide whether to grant them admin consent.
Other considerations for reducing friction
To minimize impact on trusted, business-critical applications that are already in use, consider proactively granting administrator consent to applications that have a high number of user consent grants:
Take an inventory of the apps already added to your organization with high usage, based on sign-in logs or consent grant activity. You can use a PowerShell script to quickly and easily discover applications with a large number of user consent grants.
Evaluate the top applications to grant admin consent.
Carefully evaluate an application before granting tenant-wide admin consent, even if many users in the organization have already consented for themselves.
For each approved application, grant tenant-wide admin consent and consider restricting user access by requiring user assignment.
Evaluate a request for tenant-wide admin consent
Granting tenant-wide admin consent is a sensitive operation. Permissions will be granted on behalf of the entire organization, and they can include permissions to attempt highly privileged operations. Examples of such operations are role management, full access to all mailboxes or all sites, and full user impersonation.
Before you grant tenant-wide admin consent, it's important to ensure that you trust the application and the application publisher for the level of access you're granting. If you aren't confident that you understand who controls the application and why the application is requesting the permissions, do not grant consent.
When you're evaluating a request to grant admin consent, here are some recommendations to consider:
Understand the permissions and consent framework in the Microsoft identity platform.
Understand the difference between delegated permissions and application permissions.
Application permissions allow the application to access the data for the entire organization, without any user interaction. Delegated permissions allow the application to act on behalf of a user who was signed into the application at some point.
Understand the permissions that are being requested.
The permissions requested by the application are listed in the consent prompt. Expanding the permission title displays the permission’s description. The description for application permissions generally end in "without a signed-in user." The description for delegated permissions generally end with "on behalf of the signed-in user." Permissions for the Microsoft Graph API are described in Microsoft Graph Permissions Reference. Refer to the documentation for other APIs to understand the permissions they expose.
If you don't understand a permission that's being requested, do not grant consent.
Understand which application is requesting permissions and who published the application.
Be wary of malicious applications that try to look like other applications.
If you doubt the legitimacy of an application or its publisher, do not grant consent. Instead, seek confirmation (for example, directly from the application publisher).
Ensure that the requested permissions are aligned with the features you expect from the application.
For example, an application that offers SharePoint site management might require delegated access to read all site collections, but it wouldn't necessarily need full access to all mailboxes, or full impersonation privileges in the directory.
If you suspect that the application is requesting more permissions than it needs, do not grant consent. Contact the application publisher to obtain more details.
Grant tenant-wide admin consent
For step-by-step instructions for granting tenant-wide admin consent from the Azure portal, see Grant tenant-wide admin consent to an application.
Grant consent on behalf of a specific user
Instead of granting consent for the entire organization, an administrator can also use the Microsoft Graph API to grant consent to delegated permissions on behalf of a single user. For a detailed example that uses Microsoft Graph PowerShell, see Grant consent on behalf of a single user by using PowerShell.
Limit user access to applications
User access to applications can still be limited even when tenant-wide admin consent has been granted. For more information about how to require user assignment to an application, see Methods for assigning users and groups. Administrators can also limit user access to applications by disabling all future user consent operations to any application.
For a broader overview, including how to handle more complex scenarios, see Use Azure Active Directory (Azure AD) for application access management.
Submit and view feedback for