This page discusses Entra ID application admin consent in the context of what the UW defines as risky permissions and its related practices.

Related pages you might be interested in:
Submit the Risky Entra ID Application Request form to request approval for an application that includes OAuth permissions requiring Admin consent.

Admin consent

Admin consent may be needed for one of three scenarios:

1. An application needs permissions of type admin. These are considered broad permissions that typically only someone with administrator level permissions could perform. A common example would be the ability to access the given application as any user without the user's knowledge or consent. There are two sub-scenarios:
   1. application permissions, i.e. the application has no users which sign in to it--it only acts on its own
   2. delegated permissions, i.e. the application has users which sign in to it--the application can only use a given permission when it has both the permission granted to itself AND the user has the relevant permission
2. An application doesn't want each user to have to consent to the permissions it needs. Many Microsoft applications have this type of experience. If there is a valid reason why users of your app shouldn't be bothered with the user consent experience, you can request admin consent.
3. Microsoft has included a delegated permission scope that is not of type admin in a set of permission scopes it no longer by default allows user consent for. This is a practice Microsoft started in July 2025. We have a couple options of how to address this scenario, and one of the possible options is admin consent. More about this scenario is covered below.

In general, our practices about approval of admin consent requests are the following:

• Consult with the "other" app owner(s) whose permissions you have requested consent for. In the case of Microsoft applications, this is the relevant UW-IT service owner. If the other app owner(s) don't think the request is appropriate, then the approval will be denied
• Determine if there is a similar prior approval which establishes precedent. This includes permissions for which specific mitigations have been established as required to proceed, as well as specific permissions we have determined we will not grant admin consent to.
• Determine if the request exceeds the business need
• Make a decision informed by two goals: enable valid business use with a minimum of friction and mitigate risks with due care for integration with UW confidential data
• All approvals are documented to comply with audits
• Decisions may be appealed to the UW-IT Microsoft Change Advisory Board

Scenarios for which the UW will not grant admin consent

If a 3rd party application does not have Microsoft publisher verification we are less inclined to grant admin consent. The Microsoft publisher verification program has information at https://learn.microsoft.com/en-us/entra/identity-platform/publisher-verification-overview, and most vendors go through this verification process to ensure customers trust their application. If a vendor isn't willing to go through this process, it is an indication that something is not right. The consent dialog will show "Unverified" if the application has no publisher verification.

3rd party applications which only have delegated permission scopes that are not of type admin, but require admin consent, are also a scenario for which we are generally unwilling to grant consent. This is a scenario where the request exceeds the business need. User consent would work fine for the delegated permission scopes, so the design of the application is such that it is forcing enterprises to accept the application for all users or not allow it for any users. There are exceptions to this general rule where a 3rd party application has publisher verification and there is a large UW user population that will be using the application.

Permission scopes for which the UW will not grant customers admin consent

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	This grants access to Office 365 groups with hidden membership.
MSGraph: GroupMember.Read.All	This grants access to Office 365 groups with hidden membership.
MSGraph: Groups.ReadWrite.All	Inappropriate to grant write access to all groups.
MSGraph: User.ReadWrite.All	Inappropriate to grant write access to all users.
MSGraph: Member.Read.Hidden	This grants access to Office 365 groups with hidden membership.
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	This provides access to Intune service configuration. Intune at the UW is in containment and is planned to be centrally managed by UW-IT.
Intune: update_device_attributes	Intune at the UW is in containment, and having the ability to update every Intune managed device is inappropriate.
Intune: update_device_health	Intune at the UW is in containment, and having the ability to update every Intune managed device is inappropriate.
Intune: manage_partner_compliance_policy	Intune at the UW is in containment and is planned to be centrally managed by UW-IT. If 3rd party partners need this permission it would be a planned part of a central service offering.
Office 365 Management API: ActivityFeed.Read	This grants access to all Teams channels. This broad level of access is inappropriate.

Permission scopes for which we will grant admin consent, but only under specific circumstances

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	Inappropriate to grant read or write access to all user's mailboxes. Must use the approaches noted at 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	Inappropriate to grant read or write access to all Sharepoint Online sites. Must use the approaches noted at Programmatic access to a SharePoint Online site - IT Connect (uw.edu)
MSGraph: User.Invite.All	This grants the ability to programmatically invite guest users. Any member user in our Entra tenant can interactively invite guest users. Programmatically inviting guest users is generally inappropriate, except as a centrally managed activity, since it adds the potential for significant risk to the institution given the larger scale that it enables.

Scenario #3: Permission scopes for which Microsoft forces an admin consent experience

We introduced the possibility of this scenario above. To review, some applications might involve only delegated permission scopes that are not of type admin, but still require admin consent. This is because Microsoft has decided that some permission scopes are generally dangerous to allow user consent, so has introduced this new behavior. 

The set of permission scopes which have this behavior are:

API & Permission Scope	Explanation
MSGraph: Files.Read.All (delegated) MSGraph: Files.ReadWrite.All (delegated) MSGraph: Sites.Read.All (delegated) MSGraph: Sites.ReadWrite.All (delegated)	Microsoft introduced protections for Sharepoint Online and OneDrive for Business via MC1097272.
MSGraph: Calendars.?? (delegated) MSGraph: Channel.?? (delegated) MSGraph: ChannelMessage.?? (delegated) MSGraph: Chat.?? (delegated) MSGraph: ChatMessage.?? (delegated) MSGraph: Contacts.?? (delegated) MSGraph: EAS.?? (delegated) MSGraph: EWS.?? (delegated) MSGraph: IMAP.?? (delegated) MSGraph: Mail.?? (delegated) MSGraph: MailboxFolder.?? (delegated) MSGraph: MailboxItem.?? (delegated) MSGraph: MailboxSettings.?? (delegated) MSGraph: OnlineMeetings.?? (delegated) MSGraph: POP.?? (delegated) MSGraph: TeamsActivity.?? (delegated) MSGraph: TeamsAppInstallation.?? (delegated) MSGraph: TeamsTab.?? (delegated) MSGraph: TeamTemplates.?? (delegated) MSGraph: TeamworkAppSettings.?? (delegated)	Microsoft will introduce protections for Exchange Online and Team via MC1163922 in late October. The specific permission scopes have not been documented by Microsoft at the time of this document's last update so the possible scope ranges are included.

For this scenario, we have several options for how to address the forced admin consent experience. The options are:

1. Grant admin consent. This option is possible for the following scenarios:
   1. This application's home tenant is the UW tenant, there is a valid business need, and there are no security concerns
   2. The 3rd party application has publisher verification, there is a large UW user population that will be using the application, and there are no security concerns
2. Add application to a custom consent policy that reverts the consent behavior, re-allowing user consent. This option is possible for the following scenarios:
   1. This application's home tenant is the UW tenant, there is a valid business need, and there are no security concerns
   2. The 3rd party application has publisher verification, and there are no security concerns

If you feel your application qualifies for one of the above solutions, you can request that we consider it.

The UW may further shift its user consent practices in the future to add additional options for this general scenario of forced admin consent. This topic is under discussion due to the significant changes Microsoft has made in how user consent operates.

Risky Entra ID application overview

UW-IT monitors the enterprise Entra ID tenant for Entra ID applications which have a set of permissions which we've determined are risky for the UW. When we detect an application with risky permissions, which hasn't been explicitly approved, we raise alerts that result in that application being disabled and put in a review process. If judged to be OK, the application is re-enabled, otherwise the application is deleted.

Risky Entra ID application permissions

The permissions UW-IT currently considers risky are:

• Any permission with a type of admin. Permissions with the admin type are considered broad permissions that typically only someone with administrator level permissions could perform. A common example would be the ability to access the given application as any user without the user's knowledge or consent.

If you'd like UW-IT to consider adding additional permissions to what it considers risky, please send an email to help@uw.edu with "Entra ID risky permission request" in the subject line. The service manager and owner will consider your request. If they deny your request and you disagree, you have the right to escalate to the UW-IT Microsoft change advisory board. If they agree, we'll add your permissions to the set of risky permissions that we monitor for. All risky permissions that are monitored for will be documented here.

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

More details

An example of an Entra ID application is the Microsoft Graph API. This Entra ID application identity is used by a RESTful web service interface by which you can query information about your Entra ID tenant. The Microsoft Graph API Entra ID application identity has 3 user permissions and 6 admin permissions. These are listed below to provide a concrete example of the kinds of permissions that an Entra ID application identity may provide--and that another Entra ID application identity may want to get access to. Admin permissions for Microsoft Graph API

• Read hidden memberships [Member.Read.Hidden]
• Read all users' full profiles [User.Read.All]
• Read all groups [Group.Read.All]
• Write all groups [Group.Write.All]
• Read and write all directory data [Directory.ReadWrite.All]
• Read all directory data [Directory.Read.All]

User permissions for Microsoft Graph API

• Sign in and read user profile [User.Read]
• Read all users' basic profiles [User.ReadBasic.All]
• Access the directory as the signed-in user [Directory.AccessAsUser.All]

So if a given Entra ID application was added to the UW Entra ID tenant and required 'Member.Read.Hidden' or 'Directory.Read.All' we'd detect that and flag that Entra ID application as having a risky permission. It would be disabled and reviewed.