The Stealthy Rise of OAuth Application Risk: Why Non-Human Identities are the New Security Frontier

Key Highlights

• OAuth applications now rival — and often exceed — human users in privilege, yet most enterprises lack visibility, ownership, or governance over them.
  
• OAuth access routinely survives MFA rollout, password resets, and employee off-boarding, creating long-lived “immortal” identities with persistent access to sensitive data.
  
• Attackers are increasingly exploiting OAuth to gain stealthy, durable access, bypassing traditional security controls by operating as trusted business integrations.

The Persistence Problem: Why OAuth Access Survives MFA and Employee Off-boarding

OAuth applications have become foundational to how modern enterprises operate, enabling automation, integration, and seamless data flow across cloud platforms and business systems. At the same time, these OAuth-based application identities now represent some of the most powerful identities in the organization. Unlike human users, they authenticate using tokens and API keys, operate continuously without supervision, and are frequently granted broad, long-lived access to core enterprise data and APIs.

Once consent is granted, OAuth access often persists beyond employee role changes, password resets, MFA enforcement, and even user off-boarding. In many organizations, these non-human identities sit outside formal identity governance, data ownership, and lifecycle management processes—creating material risk to operational continuity, data protection, and regulatory compliance.

This governance gap has not gone unnoticed by attackers. OAuth abuse is increasingly used to establish durable access to enterprise environments and to exfiltrate sensitive data while blending in as legitimate business integrations. Because OAuth activity appears as normal API traffic, it often bypasses traditional endpoint, network, and user-centric security controls.

For CIOs, CDOs, and CISOs, unmanaged OAuth applications represent a shared responsibility and a systemic risk spanning IT operations, data governance, and security. Addressing this risk requires applying the same discipline used for human identities: clear ownership, classification, continuous monitoring, and well-defined lifecycle controls.

In this blog, we present an executive-level framework to help technology and security leaders evaluate, classify, and govern OAuth applications across the enterprise—supported by real-world examples in which high-risk and malicious applications were identified and removed before causing operational disruption, data loss, or compliance impact.

Defining OAuth Applications: Non-Human Identities and API-Based Authentication

OAuth applications are non-human, software-based identities that enable integration, automation, and data exchange across modern digital platforms. They are widely used across cloud providers, SaaS applications, and enterprise APIs to allow systems to access data and services on behalf of users or organizations.

Unlike human users, OAuth applications authenticate using tokens, secrets, or certificates rather than passwords. This allows them to operate continuously and autonomously in the background, often with broad and long-lived access to sensitive enterprise systems and data. While this model is foundational to modern digital operations, it also introduces governance, visibility, and lifecycle challenges that extend beyond traditional identity management.

A Shared Responsibility: Aligning CIO, CDO, and CISO Offices on OAuth Governance

Once an OAuth application is granted consent, it can retain access indefinitely. Password resets, MFA enforcement, and even user off-boarding do not revoke previously authorized application access. In many enterprises, OAuth applications are implicitly trusted because they enable business operations. Yet, they are reviewed far less frequently than human users and often lack clear ownership.

This creates a structural gap between executive functions. CIO organizations typically own application enablement and integration velocity, CDO teams focus on data availability and usage, while CISOs are tasked with reducing risk and enforcing security controls. 

OAuth applications sit at the intersection of all three. Nevertheless, they frequently fall outside the formal accountability of any single office. As a result, visibility is fragmented, ownership is unclear, and decision-making around revocation or remediation is slow and contentious.

From a detection standpoint, OAuth abuse is particularly difficult to identify. Malicious or over-privileged applications generate legitimate-looking API traffic, blend into normal business workflows, and bypass traditional endpoint, identity, and user-behavior monitoring. Acting on these risks is equally challenging: disabling an application can disrupt business processes, impact data pipelines, or break critical integrations, hence creating hesitation even when risk is identified.

For CIOs, CDOs, and CISOs, unmanaged OAuth applications represent a systemic enterprise risk that spans operational resilience, data governance, regulatory compliance, and security posture. Addressing this risk requires shared ownership, clear governance models, and continuous oversight. Therefore, treating OAuth applications as first-class identities with defined lifecycle, risk classification, and executive accountability.

The Cyera Research Framework: 3 Pillars of OAuth Evaluation and Classification

As part of our commitment to our customers Cyera Research Labs drafted a framework to evaluate and manage Oauth applications. It contains a layer of evaluation and classification for the applications.

Step 1: Automated Detection via Behavioral Signals and Metadata Ingestion

Per each application ingest all the relevant data and metadata related to the application. 

Per each application ingest all the relevant invaluable data and metadata points that are translated into raw data, we incorporate multiple behavioral and contextual signals, and we also utilize 3^rd party threat intelligence to evaluate and enrich our collected data.

The decision about an application is considered based on a reputation-based model and a Known-malicious-based model, which is translated into a classification, whether this application is malicious, suspicious or benign.

The following metrics are evaluated and scored:

• A known malicious application is identified and marked as malicious. We use our own sources as well as integrate a 3^rd party service to identify and mark known malicious Oauth applications.

• We evaluate the application’s metadata and description. The name of the application can lead to detection of application impersonation for instance. For example: An application using the same name as a well-known legitimate app, but with a different organisational marker and installed in a very small number of customer environments. So, if an application is named Microsoft Calculator but the organizational ID is different and it is installed in 2 environments.

• Evaluating the publisher. We evaluate the publisher’s track record, including other applications as well as metadata and history. For instance, a single publisher is offering mutually exclusive applications (for example: “OneDrive” and “Slack”).

• Extracting and identifying malicious URLs. Each application can contain several URLs that are used as part of its activity. URLs can be configured in various meta-date points to instance download URL, or other pointers to URLs, so we can scan the URLs and check them against URLs confirmed as malicious via VirusTotal or similar services. For instance, a homepage domain that does not match reply URLs domains. In this case, we also integrated 3^rd party threat intelligence services to evaluate these URLs.

• Internal inconsistencies in the requested permissions. We identify inconsistency between the requested permissions and the goal or purpose of the application.

• Analyzing the application’s behavioral markers. We also analyze the audit logs of applications and identity of the users, leading to robust behavioral analytics that help secure your environments from rogue Oauth applications.

Step 2: Reputation Scoring and Malicious App Classification 

Per each application, we conduct the above-mentioned evaluation. Each small data point is scored with value, and level of confidence. Based on the scores we developed a rule-based decision model. Then, each application is be classified for 1 of 3 classes: Benign, Suspicious or Malicious:

• Malicious Application: An application that was marked as malicious with 100% level of confidence.
• Suspicious Applications: An application that cannot be conclusively classified as malicious, but for which there is sufficient evidence to raise suspicion of malicious or abusive behavior. In other words, the level of confidence is less than 99% but above 25%.
• Benign Applications: All the rest.

Incident Response: Protocol for Remediating Malicious OAuth Applications

Once a malicious or suspicious application is detected it is imperative to take immediate action. A malicious application in your environment represents a serious security threat. This remains true even if the application is currently disabled or has limited permissions. Thus, once you mark an application as malicious you must consider it as a breach event and act according to your protocol.

OAuth Exploits in the Wild: Case Studies on Unicode Phishing and AiTM Attacks

During this research and after implementing these stages in our everyday practice, Cyera Research Labs researchers identified various serious real-world campaigns. Below are a few case studies to illustrate the threat and urgency on this matter:

Case Study #1 - Cyrillic Espionage: A Previously Undetected Campaign

We detected across several customer environments, 5 malicious applications. While the applications were installed in November-December 2019, 6 instances were still enabled and active.

The applications were masquerading as legitimate Microsoft applications. It is very hard to distinguish the Unicode homoglyph characters, visually resembling legitimate Microsoft services:

• ShaгePoint Online
• ОпeDrive for Business
• OneDгive for Business
• Мicгoѕоft. Сloud App Ѕесuгity
• ShaгеPoint Cloud

These differences are nearly indistinguishable briefly, yet trivial for attackers to exploit. We connected all these applications to a single campaign because they share the same URLs and published organization ID.

These applications were granted vast permissions including read and write to files, mail, Teams and offline access. Combining all of these together leads to a well-crafted long lasting undetected espionage campaign that puts organizations across the world at serious risk.

In this specific campaign we also saw the reply URL - privat-sparkasse[.]de. 

A threat intelligence source linked this URL to AsyncRAT malware, read more here.

Case Study #2 - SANS Data Breach

SANS reported about a serious data breach in 2020, you can see a video about it here.

We identified in a Cyera customer’s environment two applications (“Excel4Enabler” and “SettingsEnabler”) with reply URL – https[:]//iwljzmwhres67fh[.]com/office.

These applications were installed during 2020 (similar to the SANS event) and were granted a broad and highly sensitive set of permissions, including read and write to files, read mail, mailbox settings, and offline access.

Case Study #3 - AiTM Campaign (2025)

A more recent campaign of Attacker in The Middle (AiTM) was launched in January 2025 and involved a wide phishing campaign. We discovered multiple applications masquerading events: Docusign, sharedoc, Adobe which were not created by the original organizations.

In the reply URL there was a distinct pattern of a sub-domain under an online marketing platform and software tool that helps businesses create and manage sales funnels.

https://<<subdomain>>.myclickfunnels.com/<<library>>

All applications were installed between February and March 2025, some were removed due to policy violations, but some were still active and remained undetected.

When we inspected these URLs with urlscan.io website, the URL was marked as “malicious activity” and our URL was linked to another URL which displayed this Microsoft login page, but the URL itself isn’t owned by or linked to Microsoft.

Board‑Level Takeaway

Oauth application abuse is not an edge case, but a well targeted and systemic identity risk. In many of the known cases that we found, despite being part of a publicly documented phishing campaign, these applications were still enabled at the time of our investigation.

With Cyera’s classification engine, we determined that these applications had access to over one million sensitive records, including large volumes of PII and, most concerningly, passwords.

These findings underscores how application-based attacks can quietly persist long after the initial campaign has faded from attention.

Executive awareness and governance are required to prevent silent, long‑term data exposure. 

About Cyera Research

Cyera Research is the data-centric research arm of Cyera, dedicated to advancing how organizations understand, secure, and govern data and AI risk. Our team of researchers, scientists, and cloud experts examines how data is created, accessed, and shared across complex environments to uncover emerging threats, AI-driven risks, and real-world exposure. By transforming deep data insights into decisive security action, we produce rigorous, evidence-based analysis and practical guidance that empowers security and data leaders to protect and govern their data and AI assets with confidence. 

OAuth Security and Identity Governance FAQs

Q: What is an OAuth application identity risk?

A: OAuth identity risk occurs when third-party applications are granted persistent access tokens to enterprise data. Unlike human users, these "non-human identities" often bypass Multi-Factor Authentication (MFA) and password resets, allowing attackers to maintain long-term, stealthy access to sensitive environments.

Q: Why doesn’t revoking a user’s password stop an OAuth attack?

A: OAuth uses access tokens rather than credentials. Once a user grants consent, the token remains valid until it expires or is explicitly revoked via the application management portal. This means an off-boarded employee or a compromised account can still have active data streams running through an OAuth app.

Q: How can organizations detect malicious OAuth applications?

A: Organizations should use a reputation-based model that evaluates:

1. Publisher Metadata: Verifying the history and legitimacy of the app creator.
2. URL Scrutiny: Checking redirect URLs against threat intelligence databases like VirusTotal.
3. Permission Scoping: Identifying "permission creep" where an app requests more access than its function requires.
4. Behavioral Analytics: Monitoring API traffic for anomalies that deviate from standard business integrations.

Q: What is an AiTM (Attacker-in-The-Middle) OAuth campaign?

A: AiTM campaigns use sophisticated phishing to intercept session tokens or trick users into consenting to malicious OAuth apps. Recent 2025 campaigns have shown attackers masquerading as trusted brands like DocuSign or Adobe to exfiltrate PII and sensitive 

For a deeper dive into these findings, read the Full Technical Report on OAuth Application Risks from Cyera Research.

‍