All applications that interact with a user’s device or content require some sort of access to be granted. When working with Azure AD, applications will request access to perform certain functions, such as reading a user’s calendar, looking up a contact in the global address list, or sending mail on the user’s behalf.
In the context of OAuth 2.0 and the Microsoft identity platform, these permission definitions are called scopes. When a user or application makes a request to access a particular type of data, the requested scope is appended to the request. For example, if an application sends the request string https://graph.microsoft.com/Calendars.ReadWrite, the application is asking for the ability to read and write calendar items for the user through Microsoft Graph.
Many applications simply request the permissions they need when they need them, prompting the user to approve them. Frequently, in this scenario, an application is asking for delegated permissions—or the ability to act on behalf of the user. The app’s access is limited to what the user has the ability to access.
Another example may be configuring a service principal to monitor a mailbox and start a workflow. In this case, you may be granting application permissions, since the application is acting on its own without a signed-in user performing tasks.
Consent is the process of approving application access. Users can typically consent on their own behalf, though application permissions must be granted consent by an administrator (aptly called administrator consent). For example, when someone attempts to access an app, they may be presented with a consent screen similar to the one shown in Figure 9.6:
Figure 9.6 – Application consent screen
Administrators may also pre-authorize applications and permissions in the environment, granting consent ahead of time so that users are not prompted.
The Azure portal provides several built-in options, allowing for a range of autonomy for users when it comes to consenting to application permission requests, as shown in Figure 9.7:
Figure 9.7 – User consent settings
If you choose to allow users to consent for permitted apps and permissions, you will be prompted to classify permissions into Low, Medium, and High risk categories. The Medium and High risk categories are currently in preview.
Similarly, Admin consent settings shown in Figure 9.8 provides controls over how to configure consent workflows.
Figure 9.8 – Admin consent settings
The admin consent workflow, enabled through the Users can request admin consent to apps they are unable to consent to slider, enables users to request consent. The user is presented with an approval dialog box. After confirming the request, an admin who has been delegated as a reviewer can grant or deny the consent request.
Managing OAuth application requests
As an administrative best practice, you should periodically review OAuth application requests to ensure the applications listed are still required and that the permissions granted conform to your organization’s policies.
OAuth access and permissions can be reviewed in two places on the Microsoft 365 platform:
- Azure AD Enterprise applications
- The Microsoft 365 Defender portal
Let’s quickly take a look at each of these.