nOAuth Vulnerability: The Hidden Threat Endangering 15,000+ SaaS Apps and How to Protect Your Enterprise

A critical authentication flaw within Microsoft’s Entra ID ecosystem continues to threaten tens of thousands of enterprise applications worldwide, illustrating a profound challenge for the current state of SaaS security two years after its discovery. The vulnerability, dubbed “nOAuth,” first surfaced in June 2023 when security researchers at Descope conducted cross-tenant testing on Azure Active Directory (now Entra ID), but its persistence highlights lingering issues in both vendor awareness and common implementation practices.

Dissecting the nOAuth Vulnerability​

At its core, nOAuth is an authentication implementation flaw affecting Microsoft’s Entra ID multi-tenant Open Authorization (OAuth) integrations, particularly within Software-as-a-Service (SaaS) environments that leverage OpenID Connect (OIDC) for federated identity. OAuth 2.0 is a widely adopted, token-based framework facilitating delegated access: it lets users grant third-party applications access to private resources without exposing their credentials. OpenID Connect extends this by layering identity—using secure JSON Web Tokens (JWTs) to validate users and exchange profile information.
The nOAuth flaw emerges when application developers permit unverified email claims as user identifiers within Entra ID’s OAuth flow. While OpenID Connect standards explicitly warn against using unverified email fields for authentication, insecure coding patterns persist. By exploiting this misconfiguration, attackers only need an Entra tenant and a victim’s email address to impersonate the target account across affected SaaS platforms. This approach circumvents defenses that depend on traditional identity verification because the underlying issue is with the architecture and logic, not with credential theft or brute force attacks.
What makes nOAuth especially alarming is its resilience against well-established security mechanisms. Multi-factor authentication (MFA), conditional access policies, and even mature Zero Trust architectures provide no defense. The flaw takes place upstream of these controls; if the identity provider blindly accepts an unverified claim, downstream protections are rendered moot.

Scale: 15,000+ SaaS Apps at Risk​

Data unveiled at the TROOPERS25 security conference by Semperis, an identity security vendor, punctuates the severity of the problem. According to their research presented in June 2025, at least 10% of all SaaS applications—roughly 15,000 out of an estimated 150,000—remain vulnerable to nOAuth attacks. This figure is not just speculation: Semperis’ Chief Identity Architect, Eric Woodruff, highlighted that these exposures persist because many SaaS vendors are either unaware of the issue or lack the technical expertise to identify vulnerable implementations.
The current state of remediation is concerning. Despite two years of awareness, the flaw “continues to go undetected by SaaS vendors, who may not even know what to look for and it is nearly impossible for enterprise customers to defend against, allowing attackers to take over accounts and exfiltrate data,” according to Semperis’ report.
Woodruff characterized nOAuth as a “severe” threat, emphasizing its low technical complexity and the near-impossibility of effective customer-side mitigation. “It’s easy for well-meaning developers to follow insecure patterns without realizing it and in many cases, they don’t even know what to look for. Meanwhile, customers are left with no way to detect or stop the attack, making this an especially dangerous and persistent threat,” he told attendees.

Why Traditional Defenses Fail​

Many organizations have invested heavily in comprehensive security frameworks, often centered on the Zero Trust model. This approach assumes breach by default, mandating continual identity verification for every access attempt. However, nOAuth operates beneath these layers: if the foundational identity assertion is incorrect, subsequent controls are undermined.

• Multi-Factor Authentication (MFA): Normally required following initial login, but if the attacker can supply an accepted identity claim, the system may initiate a session without triggering MFA.
• Conditional Access Policies: These check context, device posture, and user risk, but are only as strong as the initial authentication event. If an attacker’s claim is wrongly accepted as genuine, the conditional logic is subverted.
• Zero Trust Security: Relies on validated identity. If an attacker triggers the workflow with a forged or unverified email claim, subsequent evaluations are built on false premises.

This exposes a fundamental limitation: all modern identity-centric defenses require rigorous adherence to secure authentication and user claim validation at the integration level. Any misstep here reverberates through the entire SaaS security stack.

The Roots: Insecure OAuth Patterns​

To understand nOAuth, it’s vital to examine the technical pattern that allows for exploitation. OpenID Connect, building on OAuth, provides clear specifications for identity assurance. One crucial anti-pattern described in the standard is the use of unverified email claims to establish the user’s unique identity. Secure applications should only trust email attributes that are cryptographically verified—ideally provided by a trusted, validated identity provider and subject to further proof (such as domain validation or direct user interaction).
However, in the rush for rapid cloud adoption and the push for seamless integration, many development teams opt for convenience over thoroughness:

• Using the raw email field returned by Entra ID, even if it is not verified,
• Mapping user accounts based solely on this value,
• Overlooking guidance that mandates explicit verification of claims before granting sensitive resource access.

This logic flaw is particularly insidious because it does not surface as a coding bug or runtime exception. Instead, it is a “silent misconfiguration,” invisible amidst otherwise successful user experiences.

Example Attack Scenario​

Consider a multi-tenant SaaS application that leverages Entra ID for Single Sign-On (SSO). The application accepts any OAuth-based identity token that presents a correctly formatted email, without verifying if the claim is genuinely tied to the signed-in user.
An attacker, knowing the email address of a legitimate target within an organization, can:

• Register their own Azure AD tenant.
• Initiate authentication with the SaaS app, requesting access for the legitimate user’s email address.
• The SaaS app receives a token, sees an email claim matching an existing user, and grants access.
• No secondary validation, no alerts—the attacker is now inside the account and can explore or exfiltrate sensitive data.

Even if additional MFA is configured, it may only be triggered during initial account setup. Since the app mistakes the attacker as a pre-existing, valid user, no additional barriers are invoked.

Challenges in Detection and Response​

One of the most daunting aspects of nOAuth is the near-total opacity it presents to defenders. Conventional SIEM (Security Information and Event Management) or identity activity monitoring solutions rely on logging identifiable anomalies. However, nOAuth attacks are indistinguishable from normal OAuth logins—the attacker presents a validly structured request, so there is no anomaly to detect by traditional means.
Furthermore, because the exploit occurs due to incorrect app logic, not a vulnerability in the Microsoft platform per se, patching requires each affected SaaS vendor to rewrite authentication code and to shift to using only verified claims.

• Enterprise customers are powerless: Since the developer controls which claims are used for identification, organizations consuming vulnerable SaaS apps cannot unilaterally protect their tenants.
• Vendors often uninformed: Without awareness of the nOAuth pattern and lacking automated detection tools, many SaaS providers have yet to audit their implementations.
• No practical compensating controls: At present, no reliable method exists for an enterprise to detect or block nOAuth exploitation through configuration alone.

Microsoft’s Position and Vendor Responsibility​

Microsoft’s own guidance for Azure AD/OAuth clearly warns against this anti-pattern, stressing that only verified and unique claims (such as the “oid” or object ID, or a verified user principal name) should be used to link accounts. However, because OAuth’s flexible framework accommodates a wide range of integration models, responsibility falls on each application developer to implement proper verification.
When vulnerabilities are rooted in integration practices rather than software bugs, remediation is less straightforward. It is not enough for Microsoft to patch Entra ID—the ecosystem relies on each dependent SaaS vendor updating and correctly configuring their authentication logic. This phenomenon, often called the “long tail” of cloud vulnerability, significantly prolongs real-world risk.

Recommendations for Defenders and Devs​

While the bad news is that SaaS customers cannot directly remediate nOAuth exposures in third-party applications, there are key recommendations and best practices that can reduce enterprise risk and urge SaaS developers to secure their systems.

For Customers​

• Demand Transparency: Query your SaaS vendors on how they handle user identity mapping. Specifically, ask whether they rely on email claims without verification and encourage them to adopt secure authentication best practices.
• Vendor Risk Assessments: Incorporate nOAuth awareness into vendor security questionnaires.
• Centralized Identity Provider Enforcements: Where possible, configure your identity provider to only issue tokens with verified claims and limit the ability for ambiguous identity attributes to be used in SSO flows.
• Monitoring: Watch for unusual logins or unexplained SaaS account takeovers, though this remains largely reactive.

For SaaS Vendors​

• Audit Authentication Logic: Review every integration that uses Entra ID/OAuth. Ensure only cryptographically verified and immutable identifiers are used to link user accounts.
• Follow OpenID Connect Standards: Explicitly check for and reject unverified email fields when mapping users.
• Update Documentation: Provide clear implementation guidance to development teams building new integrations.
• Participate in Security Communities: Track evolving identity security threats and collaborate with peers and upstream providers to coordinate remediation.

For Microsoft​

• Ecosystem Alerts: Proactively notify all Azure AD/Entra ID app developers and administrators of nOAuth risks.
• Default Secure Claims: Consider limiting issuance of ambiguous or unverified claims in tenant configurations or deprecating risky attributes for use in common SSO flows.
• Guidance and Audit Tools: Provide automated auditing tools to help vendors identify the misconfiguration more rapidly.

A Broader Reflection: Cloud Complexity and Shared Responsibility​

nOAuth is a textbook example of how complexity and flexibility in the cloud identity landscape can open the door to broad, persistent risk. As organizations push further into multi-cloud and SaaS-first strategies, secure-by-default practices are critical. Yet, as this episode illustrates, even well-intentioned developers can unknowingly expose customers to severe attack vectors, particularly when mature identity frameworks like OAuth are implemented in nonstandard ways.
The persistence of nOAuth in 2025—two years past its original disclosure—serves as a cautionary tale about the slow, uneven pace of cloud security hygiene. Without holistic efforts, from platform providers to application developers and vigilant customers, such flaws can continue to expose sensitive corporate data on a wide scale.

The Path Forward​

Addressing nOAuth isn’t simply a matter of patching a bug; it requires a coordinated, systemic remediation effort across the SaaS marketplace. The lessons are clear:

• Identity implementation is not just a technical exercise but a critical security responsibility.
• Security teams must press for transparency and best practices from vendors.
• Vendors must recognize that secure authentication is foundational, not optional or supplementary.

Until widespread auditing and adoption of OpenID Connect standards occur, nOAuth and similar flaws will linger as latent risks in enterprise supply chains.
For IT and security teams, the priority now is to engage proactively—questioning, auditing, and demanding visible proof of secure identity handling from every SaaS provider. In parallel, platform giants like Microsoft must accelerate the distribution of automated detection tools and make secure configurations the norm rather than the exception.
Only then can the industry hope to close the nOAuth loophole and restore confidence in federated cloud identity for the next era of digital business.

---

Source: Infosecurity Magazine Microsoft Flaw Still Exposes SaaS Apps Two Years After Discovery