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:
Risky Entra ID Application Request form (use this form if you’d like to get an application which includes OAuth permissions that require Admin consent approved)
Admin consent
Admin consent may be needed for one of two scenarios:
- 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:
- application permissions, i.e. the application has no users which sign in to it–it only acts on its own
- 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
- 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.
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
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. |
| 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. |
| 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. |
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.
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.