Azure AD OAuth Admin Consent and Risky Permissions

Last updated: January 30, 2023
Audience: IT Staff / TechnicalDecision Makers

This page discusses Azure AD 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 Azure AD 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:

  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.

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: 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.
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
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)

Risky AAD application overview

UW-IT monitors the enterprise Azure AD tenant for AAD 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 Azure AD 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 “Azure AD 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 Azure AD 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 Azure AD application is the Azure AD Graph API. This Azure AD application identity is used by a RESTful web service interface by which you can query information about your Azure AD tenant. The AAD Graph API Azure AD 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 Azure AD application identity may provide–and that another AAD 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 Azure AD application was added to our enterprise Azure AD tenant and required ‘Member.Read.Hidden’ or ‘Directory.Read.All’ we’d detect that and flag that Azure AD application as having a risky permission. It would be disabled and reviewed.