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. 

Risky Entra Application Request

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}. 

Topics on this page:

What is Admin Consent?

Admin consent may be required in four scenarios:

1. Administrator-Level Permissions

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:

    1. Application permissions: The application acts independently without interactive user sign in
    2. 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. This is common with Microsoft applications. 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. Custom App Roles

If the Entra App Registration defines custom App Roles, then the app requires admin consent, per https://learn.microsoft.com/en-us/entra/identity-platform/howto-add-app-roles-in-apps#assign-app-roles-to-applications.

When you submit a request for admin consent, UW-IT follows this process:

  1. 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.
  2. 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.
  3. Evaluate business necessity: We ensure the request doesn't exceed what's needed for the stated business purpose.
  4. Balance risk and need: We aim to enable legitimate business use with minimal friction while properly mitigating risks involving UW confidential data.
  5. 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.
MSGraph: Groups.Read.All
MSGraph: GroupMember.Read.All
MSGraph: Member.Read.Hidden
This grants access to Office 365 groups with hidden membership.
MSGraph: Groups.ReadWrite.All Write access to all groups is inappropriate. 
MSGraph: User.ReadWrite.All Write access to all users is inappropriate. 
MSGraph: Files.Read.All This grants read access to all Sharepoint Online and OneDrive for Business files. This is generally inappropriate.
MSGraph: DeviceManagementServiceConfig.Read.All
Intune: update_device_attributes
Intune: update_device_health
Intune: manage_partner_compliance_policy
Intune at the UW is in containment and is planned for central management.
Office 365 Management API: ActivityFeed.Read Grants access to all Teams channels—too broad. 
API & Permission Scope Explanation

MSGraph: Mail.Read 
MSGraph: Mail.ReadBasic
MSGraph: Mail.ReadBasic.All
MSGraph: Mail.ReadWrite.All
MSGraph: Mail.Send
MSGraph: MailboxSettings.Read
MSGraph: MailboxSettings.ReadWrite
MSGraph: Calendars.Read
MSGraph: Calendars.ReadWrite
MSGraph: Contacts.Read
MSGraph: Contacts.ReadWrite
Office 365 Exchange Online: full_access_as_app

Access to all user mailboxes is inappropriate. Must use approaches documented in  Programmatic access to an Exchange Online mailbox - IT Connect (uw.edu)
MSGraph: Sites.FullControl.All
MSGraph: Sites.Manage.All
MSGraph: Sites.Read.All
MSGraph: Sites.ReadWrite.All
Access to all SharePoint sites is inappropriate. Must use approaches documented in  Programmatic access to a SharePoint Online site - IT Connect (uw.edu)
MSGraph: User.Invite.All Programmatically inviting guest users is generally inappropriate except as a centrally managed activity due to institutional risk at scale.

Starting in 2025, Microsoft began requiring admin consent for certain delegated permissions that aren't administrator-level. These permissions are considered risky enough that user consent is no longer allowed by default.  

Affected Permissions

Permission Category Permissions

Sharepoint Online and OneDrive for Business via MC1097272.

MSGraph: Files.Read.All (delegated)
MSGraph: Files.ReadWrite.All (delegated)
MSGraph: Sites.Read.All (delegated)
MSGraph: Sites.ReadWrite.All (delegated)

Exchange Online and Teams via MC1163922.

MSGraph: Calendars.Read (delegated)
MSGraph: Calendars.Read.Shared (delegated)
MSGraph: Calendars.ReadBasic (delegated)
MSGraph: Calendars.ReadBasic.Shared (delegated)
MSGraph: Calendars.ReadWrite (delegated)
MSGraph: Calendars.ReadWrite.Shared (delegated)
MSGraph: ChannelMessage.Read.All (delegated)
MSGraph: Chat.Read (delegated)
MSGraph: Chat.ReadWrite (delegated)
MSGraph: EAS.AccessAsUser.All (delegated)
MSGraph: EWS.AccessAsUser.All (delegated)
MSGraph: IMAP.AccessAsUser.All (delegated)
MSGraph: Mail.Read (delegated)
MSGraph: Mail.Read.Shared (delegated)
MSGraph: Mail.ReadBasic (delegated)
MSGraph: Mail.ReadBasic.Shared (delegated)
MSGraph: Mail.ReadWrite (delegated)
MSGraph: Mail.ReadWrite.Shared (delegated)
MSGraph: MailboxItem.Read (delegated)
MSGraph: OnlineMeetings.Read (delegated)
MSGraph: OnlineMeetings.ReadWrite (delegated)
MSGraph: OnlineMeetingsRecording.Read.All (delegated)
MSGraph: OnlineMeetingTranscript.Read.All (delegated)
MSGraph: POP.AccessAsUser.All (delegated)

Options for These Permissions

We have two potential solutions:

Option 1: Add to Custom Consent Policy

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:

  1. Alerts are raised
  2. The application is disabled
  3. The application enters a review process
  4. 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}