OAuth consent phishing explained and prevented

In this series, we've investigated identity attacks that go beyond simple multifactor authentication (MFA), including Adversary-in-the-Middle (AiTM) phishing and Golden SAML attacks . In this installment, we’ll delve into the OAuth consent phishing attack. This attack leverages the OAuth 2.0 protocol, which is widely used for granting third-party applications access to user data without sharing user credentials.

As a reminder, the most common attack is account compromise. That’s why it’s so crucial to secure your identity infrastructure, for example, by adopting phishing-resistant MFA.   

It’s important to understand the OAuth consent phishing attack because, as with token theft and token forgery, the user’s authentication method doesn't matter. When users grant consent to an OAuth application, the app can then make API calls on that user’s behalf using whatever permissions they have delegated to the app—no credentials needed.

This is great unless the app is malicious. If a threat actor publishes a data-stealing app and tricks the user into granting consent, they can gain long-lasting and hard-to-detect access to your environment.

Because this attack is much less common than credential phishing, most users are less aware of it and therefore more vulnerable to it. In this article, we’ll explore the basics of OAuth consent, how the OAuth consent phishing attack works, and how you can protect your environment against it.

OAuth allows apps to use common user data in creative, productivity-enhancing ways. Revisiting our county fair analogy from earlier blogs in this series, let’s say the county fair has built an application to make it easy to share your planned activities with your friends, such as which concerts and exhibits you’ll attend, over email.

When you install and configure the app, it asks you to link it to the identity provider for your email system. You see a sign-in screen, then a simple screen that asks whether it’s ok for the application to see your contacts and send mail on your behalf.  Once you’ve selected “Accept,” the application makes it easy for you to quickly communicate your plans to your friends at the crowded fair.

Because applications like this add a lot of value, they’re fairly common. Most users have seen consent screens like the one above and have grown accustomed to accepting such requests.

Examples of OAuth consent apps include apps that invite your friends to social games or automatically save your content to a cloud storage service such as OneDrive.

In these cases, the negotiation is strictly between the application and the user. In Microsoft Entra environments, however, administrators can consent to OAuth permissions on behalf of users for apps they trust, decide which permissions users can delegate to applications, and decide what kind of applications users can consent to.

Visit our documentation for an overview of how permissions and consent work in the Microsoft identity platform or for more in-depth information on OAuth 2.0 authorization code flow.

If the company that implements the county fair app is trustworthy and responsible, sharing permissions to access my location, see my contact information, and to send an email isn’t a problem. But if they’re unethical, they might send spam to all my contacts promoting the cotton candy special at the fair or harvest my contact information for resale to other fairs.

Applications should only request the permissions they absolutely need, and they should provide clear statements about how they’ll use what’s granted. However, applications often ask for more permissions than they need to ease development or to accommodate aspirational features. As in the example above, apps can use the permissions you grant them in ways that aren’t obvious to you and which you may not like.

A more nefarious example is an application with overtly criminal intent that promises your users great features if they consent to sharing permissions, often by impersonating a legitimate application (e.g., calling itself “out100k”). It doesn’t matter whether they’re promising an entertaining game or a leap ahead in productivity—their real intent is to steal data from your organization.

Threat actors typically promote these malicious OAuth applications via email campaigns. They may also send links to malware to harvest your data for later use (or sale), steal your company’s secrets, or engage in espionage or extortion. Attackers have also compromised legitimate websites that redirect visitors to the consent experience for a malicious app.

The OAuth consent phishing attack begins the same way as a conventional credential phishing attack—with an enticing email containing a malicious link to a legitimate-looking website. Instead of leading to a fraudulent sign-in screen prompting the user to enter their password, clicking on the link leads to a consent screen like the one above. This request will seem natural and reasonable, especially since it doesn’t request credentials.

Because the consent screen is provided by the IdP system used by the resources provider (such as an email or filesharing provider) or the user, it seems legitimate. Moreover, because the consent screen comes from a large and trusted IdP like Microsoft, Meta, or Google, it looks even more legitimate and unsuspecting users will likely accept the terms.

Once the user gives consent, the application obtains an authorization code that it redeems for an access token. The application can then use that token to act within the scope of the granted permissions until the user—or you, as the administrator—explicitly revoke them.

Consent phishing attacks target users who can grant access to their personal or organizational data directly, so attackers can then gain access to legitimate cloud services (e.g., mail servers, files storage, management APIs) and retrieve users’ account data from the API resource—without any further user interaction. Depending on the permissions granted, attackers may use the access token to access other files, contacts, forwarding rules, and other profile details.

Even worse, if the user is an administrator, a successful attack could allow a malicious app to gain administrator access to your system. Threat actors, including nation-state actors, use malicious OAuth applications for attacks that, while separate from app consent phishing, still fall under the umbrella of OAuth abuse. These include command-and-control (C2) communication, backdoors, credential phishing, and redirections.

Once enticed to grant these permissions, a user who finds the application experience disappointing will be very unlikely to follow up by revoking their consent. The attacker-controlled application can then keep working in the background, even if the user signs out, to harvest your organization’s data—or worse.

In other words, while a user can only grant an application access to resources the user has access to, once they have given this permission to the app, the app can act even when the user isn’t present. Once they gain unauthorized access to your environment, the attacker can persist, doing reconnaissance to further compromise the network.

For an in-depth analysis of a consent phishing campaign by Microsoft’s Threat Intelligence team, review this blog.

If at any time Microsoft determines that an app violates the terms of service, we disable the application and block access in Microsoft Entra ID to prevent further use across all Microsoft services. In some instances, we’ve even taken legal action to protect our customers.

The most powerful measure for stopping malicious applications is knowledge and accountability of the application’s publisher. To help you establish this trust, we created the application publication verification system. After Microsoft verifies the identity of the organization publishing an app, the app displays a blue verified badge in the Microsoft Entra consent prompt and other relevant pages. This process helps ensure the authenticity of app developers who integrate their applications with the Microsoft identity platform.

For an overview of publisher verification, see our documentation.

The best way to protect against OAuth consent phishing attacks is to prevent users from consenting to untrustworthy applications through a combination of technical controls and proactive governance.

The first step is to configure app consent policies that control which applications users can authorize. The recommended settings in Microsoft Entra restrict user consent to approved categories of applications, such as those developed in-house or by verified publishers, and to low-risk permissions. You can also create custom consent policies that dictate the conditions for allowing users to grant consent for specific apps, publishers, or permissions. 

To ensure customers stay secure in an evolving risk landscape, a Microsoft managed consent policy (built-in policy) will be enabled by default starting in July 2025. With this change, by default users will be unable to consent to third-party applications accessing their files and sites. Instead, they can request administrators to consent on their behalf, including through the Admin Consent workflow. Additional changes to the Microsoft managed consent policy will be announced in the coming months.  

With risk-based step-up consent, Entra ID automatically blocks end users from granting consent to apps considered potentially risky, such as a multi-tenant app without a verified publisher. When Entra detects a risky user consent request, it requires a "step-up" to require admin approval instead. This prevents users from directly consenting to suspicious apps they may encounter by visiting phishing URLs. This capability is enabled by default. 

Even if an application does have a verified publisher, it's still important to evaluate the consent prompt to ensure the requested permissions align with the scenario the app will enable. 

For instructions on how to configure user consent to applications, see our documentation. 

You can stop OAuth consent phishing attacks initiated via email with anti-phishing policies that prevent those emails from ever reaching your users in the first place. Microsoft Defender for Office 365 uses advanced filtering technologies backed by machine learning, IP and URL reputation systems, and an unparalleled breadth of signals to protect against phishing and other malicious emails, such as campaigns that impersonate a known user in your organization.

To help ensure that Microsoft Defender for Office 365 provides protection against the latest OAuth phishing attacks and other threats, Microsoft researchers track OAuth 2.0 URL techniques and provide feedback to email filtering systems.

You can learn more about anti-phishing policies in Microsoft 365 in our documentation.

App governance in Defender for Cloud Apps can help you make informed decisions around blocking or restricting apps that present significant risk to your organization. You can see which user-installed OAuth applications have access to data on Microsoft 365, Google Workspace, and Salesforce. You can also learn which permissions each app has, and which users have granted access to their accounts. You can also widely approve or ban permissions requests.

You can then create proactive policies to monitor how these apps, and the users of them, access, use, and share sensitive data in Microsoft 365 and other cloud platforms. Policy-driven remediations, powered by machine learning, can help you address suspicious app behaviors.

You can find step-by-step instructions for getting started with app governance in our documentation.

Microsoft integrates our security solutions across identity and access management, device management, threat protection, and cloud security. The trillions of signals we receive and evaluate each day help to identify malicious apps. Administrators, users, or Microsoft security researchers may flag an OAuth application that appears to behave suspiciously.

Microsoft Entra ID offers a comprehensive suite of malicious app detection mechanisms that leverage both machine learning and heuristic-based methods. These detections operate across various stages, including app creation, user consent, graph data extraction, and verified publisher registration. Additionally, a dedicated team of human reviewers assesses suspicious apps flagged daily.

The primary objective of these detection efforts is to identify and neutralize malicious apps within the ecosystem before they can harm customers. Entra ID actively removes malicious apps identified through these processes and shares intelligence, such as app reputation scores, with protective measures in other products. This includes features like step-up consent and app detections within Defender for Cloud Apps.

To help contain potentially malicious apps, you can use Conditional Access for workload identities to create policies that block service principals based on IP ranges, risk, or authentication context.

You can find more information on securing workload identities and detecting risk in our documentation.

Microsoft Defender for Office 365 processes signals to help identify malicious apps and prevent users from accessing them. Advanced hunting capabilities in Microsoft 365 Defender can help you locate consent phishing emails and other threats. Microsoft 365 Defender consolidates and correlates email threat data from Microsoft Defender for Office 365, app signals from Microsoft Defender for Cloud Apps, and intelligence from other Microsoft services to provide a comprehensive end-to-end view of attacks.

Find step-by-step instructions on how to detect consent attacks in our documentation.

Microsoft Defender for Cloud Apps not only helps you define appropriate Microsoft 365 app behavior with data, users, and other apps, but it also helps you quickly detect when an app behaves differently than expected and disable it. You can configure Microsoft Defender for Cloud Apps policies to help manage abnormal application activity via policies that send alerts based on suspicious user activity, anomalous behavior, and conditions that you specify.

You can find more information on investigating risky OAuth apps using Microsoft Defender in our documentation.

As digital transformation moves most paper processes to the cloud and gives us far better ability to analyze and repurpose data for greater efficiency, applications are becoming the new frontier for cybersecurity. Low-code/no-code and AI- and ML-assisted development will only accelerate the explosion in new applications. The techniques outlined above will help your organization embrace the productivity benefits of this trend while minimizing the risks to your organization.

Nitika Gupta, Partner Group Product Manager

Yaron Paryanty, Principal Group Product Manager

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

• ⁠Microsoft Entra News and Insights | Microsoft Security Blog
• ⁠⁠Microsoft Entra blog | Tech Community
• ⁠Microsoft Entra documentation | Microsoft Learn
• Microsoft Entra discussions | Microsoft Community