Microsoft 365 has been providing solutions for managing risks related to OAuth applications for several years, but recent enhancements have prompted a renewed look at the topic.
This blog post is based on information available as of April 5, 2025.Some images remain in Japanese, and I apologize for that. I will correct them when I get the chance.
What is OAuth?
OAuth is an authorization framework that allows third-party applications to access specific resources or data on behalf of a user, without handling the user's credentials directly. This enables users to grant limited access rights to applications without sharing their passwords. [Source]
OAuth has evolved primarily through two versions. OAuth 1.0 was standardized in 2010, but due to implementation complexities and challenges, a simpler and improved version, OAuth 2.0, was established in 2012. Currently, many services, including Microsoft 365, utilize OAuth 2.0.
OAuth Implementation in Microsoft 365
In Microsoft 365, Entra ID provides the foundation for OAuth 2.0, displaying a 'consent screen' when users sign in to an app.
Consent screen
When consent is granted, the third-party app accesses information on the Microsoft 365 tenant based on the permissions authorized at the time of consent. [Source] Microsoft Graph, in particular, acts as a unified API for Microsoft 365 data and is often accessed via OAuth. Applications can access various resources like email, calendar, files, and chats through Microsoft Graph.
Conceptual diagram
The Situation Surrounding OAuth
While OAuth is a convenient technology, improper management can pose significant security risks to an organization.
Data Leakage Risk
A primary risk is data leakage. Seemingly harmless apps might request excessive permissions, and if users consent, oversharing of data can occur. For example, a simple PDF conversion tool might inexplicably request access to the entire mailbox (Mail.ReadWrite.All), and a user might grant consent without realizing the implications. From the user's perspective, data they thought was securely stored in Microsoft 365 could unknowingly flow to a third-party app.
Delegated Access Risk
There is a risk of damage if an app with broad delegated access scope is compromised. Particularly high-risk permission scopes include the following. Apps with these permissions effectively have extensive access across the entire tenant, enabling large-scale data theft or privilege escalation.
Mail.ReadWrite.All: Read/write access to all users' mailboxesFiles.ReadWrite.All: Read/write access to all users' OneDrive and SharePoint filesDirectory.ReadWrite.All: Read/write access to directory data (e.g., user information)User.ReadWrite.All: Read/write access to all user profiles
Long-Term Persistence Risk
OAuth tokens, once granted, remain valid until explicitly revoked. This means malicious apps can potentially persist within an environment for long periods (months to years). Since standard password changes do not invalidate these tokens, detecting compromises can be delayed. Furthermore, leaving unused OAuth app connections active creates a risk: if that app is compromised in the future, the linked account information could be exploited.
Consent Phishing Attack
This attack vector has seen a particular increase since 2020. Attackers create malicious OAuth applications disguised as legitimate ones, tricking users into granting broad permissions to exfiltrate information. A specific example is the 'OiVaVoii' campaign identified in 2023, targeting Azure and Microsoft 365. In this attack, phishing emails disguised as legitimate app requests led users to grant extensive permissions, resulting in account takeovers and other damages. [Source]
App Verification Limitations
Microsoft Entra ID includes an app verification mechanism known as 'Verified Publisher.' However, this primarily confirms the publisher's identity and does not guarantee the application itself is secure. Even apps from verified publishers might request excessive permissions or handle data improperly. Additionally, some necessary organizational apps may not have undergone publisher verification, making blanket blocking operationally challenging.
Source: Publisher verification overview
Countermeasures Available in Microsoft 365
While OAuth app risks are not exclusive to Microsoft 365, this section focuses on the countermeasures available within the Microsoft 365 ecosystem.
Prerequisite: Enable App Governance
As a prerequisite for the following countermeasures, enable App Governance in Defender for Cloud Apps.
Visualize and Control OAuth Apps Individually
The first step in countermeasures is visualizing OAuth app usage with Microsoft Defender for Cloud Apps. Microsoft Defender for Cloud Apps, a cloud app protection solution included in licenses like E5, allows you to list and view OAuth apps connected to Microsoft 365 within the Microsoft Defender XDR portal. It is highly suitable for seeing who in the organization has connected which OAuth apps.
Additionally, using the Attack Surface Map in 'Microsoft Security Exposure Management,' a solution for understanding and prioritizing organizational security risks (especially attack surfaces and vulnerabilities), customers can reportedly visualize their organization's connections to OAuth applications, including app owners and permission levels. [Source] (Note: The author has not personally accessed this feature yet). Utilizing these tools can provide input for considering high-priority countermeasures while being mindful of the potential impact scope.
Furthermore, since April 2025, this information has become searchable via queries in Defender XDR's Advanced Hunting, allowing for the extraction and targeted remediation of high-risk apps. [Source]
OAuthAppInfo
| where AppStatus == "Enabled"
| where PrivilegeLevel == "High"
| where VerifiedPublisher == "{}" and AppOrigin == "External"
Define App Consent Policies
In Entra ID, you can configure conditions for apps allowed to receive consent. To prevent users from granting permissions to unapproved apps, consider configuring user consent settings to disallow consent. Navigate to [Microsoft Entra admin center] > [Enterprise applications] > [Consent and permissions]. There, set 'User consent for applications' to 'Do not allow user consent'.
Also, enable the admin consent workflow so that users must request approval before granting access.
Then, when a user attempts to configure OAuth, they will see a screen requesting admin approval, preventing them from granting consent independently.
The administrator will receive a notification like the one below, and only after approval can the user utilize the app.
Individual Control (Revoke Access Rights)
Individual control over OAuth apps is also crucial. You can completely ban potentially risky apps, including existing ones. Navigate to 'App governance' in the Microsoft Defender XDR portal, select the specific app, and choose [Disable].
This allows control over high-risk applications and permissions, preventing inappropriate access to organizational data.
Block screen
Monitoring System
Continuous monitoring is a critical element of defense. To monitor OAuth application activity in the Microsoft 365 environment, configure alert policies in Microsoft Defender for Cloud Apps' App Governance to detect suspicious OAuth application activities. App Governance includes default monitoring policies; it's important to start with these and refine them based on your needs.
Response (Automatic Attack Disruption)
Microsoft Defender XDR offers the 'Automatic attack disruption' feature [Source]. This capability is not limited to OAuth apps; it leverages signals across Microsoft Defender XDR (Endpoint, Identity, Office 365 (email), Cloud App, etc.) using AI and machine learning to analyze attacker intent and automatically execute responses in real-time, such as isolating devices or disabling user accounts. This allows for the rapid containment of attacks, preventing further damage.
In March 2025, it was announced that automatic attack disruption would include the action of disabling malicious OAuth apps [Source]. Of course, disruption isn't guaranteed, so the countermeasures discussed earlier remain necessary. However, enabling this feature serves as a valuable final safety net against compromise. For detailed instructions on enabling it, please refer to the Microsoft documentation [Source].
Conclusion
While OAuth is convenient, it can pose significant security risks without proper management. In the Microsoft 365 environment, combining appropriate measures like app governance, consent policies, monitoring systems, and attack disruption can significantly mitigate these risks. Notably, from late 2024 through 2025, Microsoft has been enhancing its OAuth protection capabilities. Leveraging these new features allows organizations to build a more robust security posture.
However, technology alone cannot provide complete protection. Ultimately, continuous user education and security awareness training are crucial for deepening organizational understanding of OAuth application risks. Implementing these measures in a balanced way can effectively protect the organization from attacks exploiting OAuth. I hope this information is helpful.
Comments
Post a Comment