IT Connect
Your connection to information technology at the UW

Azure AD OAuth Admin Consent and Risky Permissions

This page discusses Azure AD application permissions in the context of what UW defines as risky and its practices with regard to granting Admin Consent.

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
  • Determine if there is a similar prior approval which establishes precedent
  • 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
  • Decisions may be appealed to the UW-IT Microsoft Change Advisory Board

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.

Last reviewed January 4, 2022