As you may know, it’s possible for your users to sign-in to SaaS based applications using their Azure AD account. By doing this, a Single Sign On (SSO) experience is created for the user. Before this SSO for an SaaS based application is possible though, the user needs to accept (a) permission request(s) from the application allowing the application to access the users data on its users behalf, even when the user is not using the application.

Added February 11th: Erik Loef pointed me to the following two interesting articles detailing on how oAuth can be used to exploit Office 365 environments. See:

Shining a Light on OAuth Abuse with PwnAuth
Introducing the Office 365 Attack Toolkit

Added May 20, 2020: Microsoft made some new functionality available, please also read my article: “Some welcome additions to the Admin consent workflow in Azure AD” afterwards for the changes Microsoft made.

TL;DR; – Disable user app consent, and enable admin consent requests as soon as possible!

Note: This post reflects the status of Admin consent as of February 9th 2020. Functionality may change, even right after this post has been published.

Let me give you an idea of what this first time setup looks like, I’ve taken the Sessionize SaaS application as an example.

So even though, for the user this provides a nice and user friendly experience, you should ask yourself whether you want to maintain this “default” behavior in your environment. Here is why:

Some background information first

From the documentation

The experience while signing up to sessionize.com described above is provided by the Microsoft Identity Platform (formerly Azure AD for developers). It allows developers to build applications that sign in all Microsoft identities and get tokens to call Microsoft APIs such as Microsoft Graph or APIs that developers have built.

The Microsoft identity platform implements the OAuth 2.0 authorization protocol. OAuth 2.0 is a method through which a third-party app can access web-hosted resources on behalf of a user. Any web-hosted resource that integrates with the Microsoft identity platform has a resource identifier, or Application ID URI. For example, some of Microsoft’s web-hosted resources include:

• Microsoft Graph: https://graph.microsoft.com
• Office 365 Mail API: https://outlook.office.com
• Azure AD Graph: https://graph.windows.net
• Azure Key Vault: https://vault.azure.net

By defining these types of permissions, the resource has fine-grained control over its data and how API functionality is exposed. In OAuth 2.0, these types of permissions are called scopes. They are also often referred to as permissions. A permission is represented in the Microsoft identity platform as a string value. Continuing with the Microsoft Graph example, the string value for each permission is:

• Read a user’s calendar by using Calendars.Read
• Write to a user’s calendar by using Calendars.ReadWrite
• Send mail as a user using by Mail.Send

An app most commonly requests these permissions by specifying the scopes in requests to the Microsoft identity platform authorize endpoint. However, certain high privilege permissions can only be granted through administrator consent and requested/granted using the administrator consent endpoint. If the application is requesting high privilege delegated permissions and an administrator grants these permissions via the admin consent endpoint, consent is granted for all users in the tenant. Examples of these kinds of permissions include the following:

• Read all user’s full profiles by using User.Read.All
• Write data to an organization’s directory by using Directory.ReadWrite.All
• Read all groups in an organization’s directory by using Groups.Read.All

Here is an example of the rights given to Modern Workplace Concierge, which is a great tool written by Nicola Suter to export and import all kinds of objects related to the Modern workplace using the Microsoft Graph API. In order for the Modern Workplace Concierge to work, you have to give Admin consent for your tenant.

As you can see, the Modern Workplace Concierge has some extensive rights in my tenant, it can for example ” Read and write Microsoft Intune Device Configuration and Policies”. So in theory, when the Modern Workplace Concierge somehow gets hacked, it could potentially access the Device Configuration and Policies in my tenant. Let’s hope this never happens.

Why you may want to restrict the end-users consent to applications

While in the example with Sessionize the use-case is low risk, the functionality can also be misused by people with bad intentions. Even though Microsoft has some measures in place to protect against access from applications to company wide data, having a malicious web application granted access to personal data of a user is not something which is acceptable.

Update July 8th 2020: See the following article for an interesting example: Microsoft seizes six domains used in COVID-19 phishing operations

Microsoft now also recommends to disable future user consent operations to help reduce the surface area and mitigate this risk. For some reason though, even on newly created tenants, by default the option for user to consent to applications is enabled.

How to see which applications are currently able to access data on behalf of your users

You can see the applications which interact with the Microsoft Identity Platform by going to the Azure Active Directory admin center and selecting Enterprise Applications.

For applications for which users have given consent the permissions could look like the example below, this is for the Sessionize application we used in your example.

What to do in order to regain control

Disable user consent and enable Admin consent requests.

You can disable the ability for users to consent to apps accessing company data on their behalf by going to the User settings under Enterprise Applications. By enabling Admin consent requests the user can request that an admin approves consent to applications for which they are not able to consent.

Set “Users can consent to apps accessing company data on their behalf” to No. Notice the nice remark for LinkedIn (now a Microsoft subsidiary) When set to “No”, users may still be able to connect their work or school accounts with LinkedIn.

The necessary settings might look similar to the screenshot below.

Review the current applications which received user consent, and if you don’t trust the application remove it.

Depending on the amount of applications your users have given consent this can be a challenging job. Guess you have to review each application and determine whether you want to keep approving the consent already given by your users. If you have Cloud App Security, the Cloud App catalog might help, you may decide to not allow any application with a risk score of 3 and less, which is categorized by Microsoft as “red” meaning critical.

You have the option to remove the application by going to Properties and selecting Delete, confirm by clicking Yes.

If you want to use PowerShell for your inventory, there is a script made by Vasil L. Michev over in the Technet Gallery which can help, the script can be found here: Azure AD Integrated Applications Inventory

The script lists all Azure AD integrated applications for your tenant. For each application, additional information such as the Publisher and homepage is returned. OAuth permissions required by the application are included in the output, as is information about any users that have authorized the application.

Conclusion

Even though that Microsoft recommends to disable the user consent, it’s still enabled by default. In fact, most of my customers still have the option enable, and the list of applications to which users have given consent keep growing and growing. Basically this means you are out of control and have no idea which external applications can access your user data.

I hope this article gives you some ideas on how to regain that control, one step at a time..