Managing risky 3rd party app permissions with Microsoft’s CASB

Published 10-24-2018 06:00 AM 31.2K Views

While the focus on cloud-based services continues to drive modern IT, the cloud is also making it increasingly easy for users to source new cloud applications without IT oversight in their quest for productivity. In most cases this leads to an increase in cloud-based Shadow IT across Software as a Service (SaaS) solutions, Infrastructure as a Service (IaaS), as well as connected 3rd party applications, and exposes organizations to new threats.


In this post we will discuss 3rd party app permissions as a specific form of Shadow IT and the threat vector that is created when these are authorized against sanctioned IT applications, using protocols such as Open Authentication (OAuth). Furthermore, we will review recent attacks and outline how Microsoft’s Cloud Access Security Broker (CASB) capabilities can help you gain insights into this specific form of Shadow IT and how to safely adopt OAuth apps in your environment - allowing you to balance security and user productivity.


Understanding OAuth

OAuth is a web-based industry standard protocol that enables users to grant web applications access to their accounts and data without sharing their credentials and was originally created for consumer-focused services such as Facebook or Twitter. More recently, the enterprise adoption of OAuth is increasing as a result of the continued adoption of cloud-based solutions in corporate environments, as it allows to simplify login processes across the numerous cloud applications in use.


Once a user authorizes an app, an access token is created and provides the application with programmatic access to the user’s corporate data. This process allows the application to take advantage of the assigned permissions until the token is manually revoked. Contrary to common perception, a change in the user’s password or introducing a second factor for authentication afterwards, will have no effect on the app’s access token.


Based on data from Microsoft Cloud App Security, we’re seeing a continued increase in the number of authorized 3rd party apps. While on average organizations, regardless of size, have 81 authorized OAuth apps in their environment, some organizations already have more than 250 apps.


OAuth apps as a threat vector

While extremely convenient, OAuth introduces a new threat vector to the security of organizations and enables potential back doors into corporate environments when malicious apps are authorized. OAuth was introduced as a more recent form of phishing techniques, where attackers trick users into granting access to rogue applications. Stats show that 4% of people will click on any given phishing campaign[1] with the cost averaging at $1.6 million when an organization is affected by a phishing campaign.[2]



 OAuth phishing specifically exploits the users’ inability to differentiate legitimate from rogue cloud applications. One of the most prominent attacks by the hacker group Fancy Bear in 2017, was designed to impersonate the Gmail interface and thereby steal user’s access token and gain access to their accounts.



Image 1: Impersonation attack interface by Fancy Bear in 2017Image 1: Impersonation attack interface by Fancy Bear in 2017 

In this scenario, attackers rebuild web pages to make them look nearly identical to genuine web page that users will believe they are accessing. Unless users closely inspect the web address, they may not realize that they are instead providing permissions to a rogue web application.


Unfortunately, users often click “accept” without closely reviewing the details on the permissions they are granting to individual apps - and the more privileged the user, the higher the risk of exposure. This problem is elevated by the fact that IT may have no or little insight into the apps that have been authorized or lack the tools to evaluate the security risk of an application against the productivity benefit that it provides.


Safely adopting and managing OAuth apps with Microsoft’s CASB

Microsoft Cloud App Security (MCAS) provides a comprehensive solution with reporting and analytics on the use of Shadow IT, as well as deep investigation and remediation capabilities to limit the risk and exposure for organizations.


To address the risk of 3rd party app permission, MCAS enables IT to gain an overview of authorized applications across their cloud services Office 365, Salesforce and GSuite. The capabilities allow them to continuously monitor new app permissions and provides controls to prevent and remediate malicious OAuth apps from gaining access to corporate data.


Managing app permissions

Microsoft Cloud App Security app permissions enable you to see which OAuth applications have access to Office 365, G Suite, and Salesforce data, view a full list of permissions that were granted to the app, and which users granted these apps access.


Image 2: App permission overview dashboard in Microsoft Cloud App SecurityImage 2: App permission overview dashboard in Microsoft Cloud App Security

To better understand unknown applications, admins have the ability to drill down into the details for each app and analyze them against their permission levels, the community use- which indicates how common the app is in other organizations- and view related user activities that were logged by MCAS.


Revoking risky apps and notifying users

Community use and the permission level details help admins decide which apps users are allowed to continue to access and which ones will be revoked.

Once reviewed, admins can easily mark an app as approved in the organization, to indicate that it’s been reviewed and approved for organizational use, while apps considered risky can be marked as “banned”, which will revoke the apps permissions.


For continuous monitoring of the OAuth apps connected to your envrionment, you can create permission policies that will notify admins when an OAuth app meets a set of pre-defined criteria. Admins can for example configure to be alerted when new apps that require a high permission level were authorized by a large set of users or privileged user accounts.

To minimize the impact to your organization, these alerts can be configured with governance actions to automatically revoke the permissions of an app that is considered risky.


Image 3: Alert - Detection of a new risky OAuth appImage 3: Alert - Detection of a new risky OAuth app


OAuth apps are becoming increasingly popular among end users in corporate environments, as well as attackers, that’s why it’s crucial for organizations to continually monitor authorized apps and identify risky apps quickly to limit the impact to your organization.


More info and feedback

Learn how to start managing your app permissions with Microsoft Cloud App Security using our technical documentation.

Don’t have Microsoft Cloud App Security? Start a free trial today and take a look at our datasheet for an overview of our key use cases and integrations.

As always, we want to hear from you! If you have suggestions, questions, or comments, please let us know on our Tech Community page.


[1] Verizon Data Breach Report, 2018

[2] Enterprise Phishing Resiliency and Defense Report 2017

Super Contributor

By relying upon MCAS to block bad grants after-the-fact, there is increased risk that data may have already been ex filtrated. This is a reactive approach.

The proactive approach is to prevent end-users from granting consent, so that trained IT Administrators can make qualified risk decisions. There may be valid reasons why to advocate for the reactive approach, but this article should at least point out that there is a proactive alternative available. 

( > Azure Active Directory > user settings > enterprise applications > "Users can consent to apps accessing company data on their behalf = No" 




Occasional Contributor

@Kim Kischel Thanks for the overview above. You say that "To minimize the impact to your organization, these alerts can be configured with governance actions to automatically revoke the permissions of an app that is considered risky." Since it is an alert, can you please clarify if this means [1] that the administrator on reviewing the alert can revoke permissions, or [2] MCAS will proactively revoke permissions without admin intervention on the alert being generated.

Occasional Contributor

@Kim Kischel To @Joe Stocker's point, is there a way in MCAS to scope access permissions to apps in advance of them turning up via OAuth approvals? For example, that an admin can create a list of approved apps before any user has approved them? And therefore by implication, to create a blacklist too, that works proactively?

Or is after-the-fact the only option?

Occasional Contributor

@Kim Kischel Still thinking about this one ... apologies for all the questions. The Microsoft Docs page here - - says that marking an app as approved is a visual only notification to the admin. Does this work the same way for a banned app? I read the document as saying that banning an app revokes whatever authorization are in place at that point in time, but does not prevent the user from re-approving them. Or, in other words, that it's a single point in time governance action but not a black list.

Therefore, a user could re-approve an OAuth app that was banned, and an admin would have to either manually ban it again, or if your answer to my first question above is that newly identified OAuth apps can be automatically revoked without admin intervention, that MCAS could automatically revoke it again once it sees it happening.

Is this understanding in line with how this all works, or have I mis-understood?


Hi @Michael Sampson, per your questions above:

1. MCAS allows you to set automated remediation for policy violations. In this case, once MCAS detects an OAuth app that matches the policy conditions (for example, and app that requires full access to the user's data), it can automatically revoke the permissions granted to the apps, an effectively remove it. The user will might still see the app as connected but the app won't be able to perform any action.
The remediation flow is automatically executed without any admin intervention. In addition, an alert will be triggered for auditing and further investigation.


2. Banning an apps as the app to a blacklist and covers any future permission grant to this app. 


3. Currently you can only add specific apps to the blacklist/whitelist after the app was detected. Meaning, an app need to be approved by at least 1 user in the organization in order to be shown in the App Permissions page, and then added to the blacklist (by Banning the app) or to the whitelist (by Authorizing the app). Having said that, "policy-defined blacklist", such as block all apps that require Full Data Access, can be configured proactively.




Occasional Contributor

@Niv Goldenberg Awesome answers, thank you. Greatly appreciate the clarification. I plan to sign up when I get back from an upcoming trip.



Version history
Last update:
‎May 11 2021 02:07 PM
Updated by: