Entra ID OAuth Admin Consent and Risky Permissions
Overview: This page explains UW's policies and procedures for granting admin consent to Entra ID applications. Admin consent can have broad security implications for the entire university, so all requests must be carefully reviewed to balance business needs with security risks.
Need admin consent? Submit this form to request approval for an Entra application requiring admin consent.
If you don't know the specific permission scopes but have gotten the admin consent error, please share the specific URL with us in your request. That URL should look something like this: https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}.
The application needs permissions that only administrators should grant (generally known as type admin). These permissions typically allow actions that could affect multiple users without their knowledge. There are two types:
Application permissions: The application acts independently without interactive user sign in
Delegated permissions: Users sign in to the application, which can only use permissions when both the app has permission AND the user has the relevant permission
2. Avoiding Individual User Consent
The application wants to skip the step where each user must individually consent to permissions. If there's a valid reason users shouldn't be asked to consent, you can request admin consent instead.
3. Microsoft-Restricted Delegated Permissions
As of July 2025, Microsoft no longer allows user consent for certain delegated permission scopes, even if they aren't administrator-level permissions. Admin consent is one option to address this situation, but there generally is a better solution. See detailed information below.
4. Assignment is Required and the App has Permissions that only Require User Consent
When you submit a request for admin consent, UW-IT follows this process:
Consult with affected app owners: We verify with the owners of the applications you're requesting permissions for (for Microsoft apps, this is the relevant UW-IT service owner). If they object, the request will be denied.
Check for precedent: We review similar past approvals and any required mitigations or permissions we've decided not to grant. Some of these precedents are documented below.
Evaluate business necessity: We ensure the request doesn't exceed what's needed for the stated business purpose.
Balance risk and need: We aim to enable legitimate business use with minimal friction while properly mitigating risks involving UW confidential data.
Document the decision: All approvals are recorded for audit compliance.
Appeals process: Decisions may be appealed to the UW-IT Microsoft Change Advisory Board
Applications Without Publisher Verification
We are less likely to approve third-party applications lacking Microsoft publisher verification. Most reputable vendors complete this verification process to establish trust. An "Unverified" notice in the consent dialog is a red flag. Depending on the scenario, we may overlook this.
Applications That Force Enterprise-Wide Consent
We generally won't approve third-party applications that require admin consent solely for non-administrator delegated permissions. This design forces enterprises to accept the application for all users or none at all, which exceeds business need when user consent would work fine. We can sometimes find workarounds which overcome this aggressive vendor design that is inappropriate for an enterprise at our scale and diversity.
Exception: We may make exceptions for verified third-party applications with a large UW user population.
API & Permission Scope
Reason we won't grant
MSGraph: Directory.Read.All
Grants access to all directory data regardless of its data classification. In specific, this grants access to Office 365 groups with hidden membership.
This re-enables user consent for the application. Available when one of the following conditions are valid:
The application's home tenant is UW, there's a valid business need, and no security concerns exist
The third-party application has publisher verification and has no security concerns
Option 2: Grant Admin Consent
Available when one of the following conditions are valid:
The application's home tenant is UW, there's a valid business need, and no security concerns exist
The third-party application has publisher verification, serves a large UW user population, and has no security concerns
If your application qualifies for one of these solutions, submit a request for our consideration.
Note: UW may expand the user consent options in the future as we adapt to Microsoft's significant changes in consent policies. This topic is under active discussion.
UW-IT continuously monitors the enterprise Entra ID tenant for applications with risky permissions. When we detect an unapproved application with risky permissions:
Alerts are raised
The application is disabled
The application enters a review process
If approved, the application is re-enabled; if not, it's deleted
What Qualifies as Risky?
Currently, UW-IT considers any permission with a type of admin to be risky. These are broad permissions typically requiring administrator-level authority, such as the ability to access an application as any user without their knowledge or consent.
Want to suggest additional risky permissions? Email help@uw.edu with "Entra ID risky permission request" in the subject line. The service manager will review your request.
If You've Encountered an Admin Consent Error
If you don't know the specific permission scopes but have gotten the admin consent error, please share the specific URL with us in your request. That URL should look something like this: https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}