Defenders hate it! Compromise vulnerable SaaS applications with this one weird trick

Defenders hate it! Compromise vulnerable SaaS applications with this one weird trick

Speakers: Eric Woodruff

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=rQxc9N4gBqA

Overview

Eric Woodruff, Chief Identity Architect at Semperis, presents a deep investigation into nOAuth -- a two-year-old vulnerability class in applications using OpenID Connect (OIDC) with Microsoft Entra ID that remains actively exploitable today. The vulnerability allows an attacker to impersonate any user in a SaaS application simply by knowing their email address. Woodruff's research extends the original 2023 disclosure by Descope by demonstrating that the vulnerability is not limited to cross-identity-provider attacks but works as a cross-tenant attack within Entra ID itself. Testing 104 applications from the Entra Gallery, he found 9 (8.6%) were vulnerable, including an HR platform full of PII, applications with Office 365 integrations enabling mail access, and platforms claiming 45,000+ customers. Despite coordinated disclosure with MSRC spanning over six months, Microsoft continues to characterize this as a developer problem, leaving customers with no visibility into whether the SaaS applications they rely on are vulnerable.

Background

▶ Watch: nOAuth backstory: Descope's 2023 disclosure and Microsoft's response (6:30)

The nOAuth vulnerability was originally disclosed by Omar Cohen of Descope on June 20, 2023. The core issue is an anti-pattern in OIDC implementations: applications that use the email claim from an ID token as the primary user identifier instead of immutable claims like subject (sub) or issuer (iss). The email claim is mutable -- an attacker with admin access to any Entra tenant can set any user's mail attribute to any email address without verification.

When Descope published this finding, Microsoft's MSRC responded with a blog post stating they had identified and notified affected multi-tenant applications. The security media (Hacker News, Bleeping Computer, Petri) ran headlines suggesting Microsoft had "fixed" or "patched" the issue. The reality, as Woodruff emphasizes, is that no fix was deployed -- Microsoft added a default setting (removeUnverifiedEmailClaim = true) for new app registrations created after June 2023, but the vast majority of existing applications remained unchanged.

Less than a month after the nOAuth disclosure, the Storm-0558 incident (Microsoft signing key theft) dominated security news, and nOAuth faded from attention. But the vulnerability never went away.

The timing is significant because Descope's original framing focused on cross-identity-provider attacks -- a user with a Microsoft account taking over a Google account in the same SaaS application. This framing may have led developers who only use Microsoft for authentication to dismiss the risk, thinking it only applied to multi-IDP configurations.

Key Findings

▶ Watch: Cross-tenant attack: spoofing email claims within Entra ID itself (14:00)

1. nOAuth is alive and exploitable today. Woodruff's team began active testing in late 2024, two years after the vulnerability was declared "fixed." They tested 104 OIDC applications from the Entra Gallery (a subset of all multi-tenant applications -- vendors must apply to be listed) and found 9 applications (8.6%) were vulnerable.

1. The attack works within Entra ID alone (cross-tenant). Unlike Descope's cross-IDP framing, Woodruff demonstrates that an attacker using a separate Entra tenant can exploit the same vulnerability. The attacker creates or modifies a user in their own tenant, sets the mail attribute to the target's email address via a simple Microsoft Graph API PATCH operation, and authenticates to the vulnerable SaaS application. If the application matches users by email claim, the attacker gains full access as the victim.

1. High-impact applications are vulnerable. The 9 vulnerable applications included: an HR platform (containing PII for all employees), an absence management system (still vulnerable, with PII), three knowledge sharing/collaboration platforms (one claiming 45,000+ customers, still unresolved), a business coaching platform, a construction site management platform, and two applications with Office 365 integrations (calendar access, email read/send, meeting scheduling -- effectively SaaS-to-mailbox pivot capability).

1. MSRC response was frustrating and ultimately ineffective. Woodruff opened a case with MSRC on December 3, 2024. It was acknowledged the next day and he was awarded 60 points. Then silence for months. When he asked about status in March 2025, his points were revoked. The case was eventually closed with a generic "problem fixed" response without answering any of his questions. Only as disclosure deadlines approached did Microsoft engage substantively, ultimately stating they would remove vulnerable applications from the Entra Gallery (which does not fix the vulnerability).

1. Vendor response was highly variable. Of the 9 vulnerable vendors notified starting December 2, 2024, one resolved the issue within a week. Two remained vulnerable as of the presentation. Some vendors removed their OIDC integration entirely rather than fixing it. Others erected paywalls that prevented retesting. Some could not be reached through any published security contact.

1. Customer detection is essentially impossible. The attacker authenticates through their own Entra tenant, completely bypassing the customer's conditional access policies, MFA requirements, Defender for Cloud Apps, and CASB solutions. SaaS Security Posture Management (SSPM) tools and browser security extensions do not detect this pattern. Log correlation between Entra sign-in logs and SaaS application logs is theoretically possible but practically infeasible for most organizations.

Technical Deep Dive

▶ Watch: Testing results: 9 of 104 Entra Gallery apps vulnerable (8.6%) (24:00)

The vulnerability chain exploits a fundamental property of Microsoft Entra's common endpoint architecture. Multi-tenant applications use Microsoft's common authentication endpoints (login.microsoftonline.com/common/oauth2/...), which allow users from any Entra tenant to authenticate. This is the mechanism that enables SaaS applications to serve customers across multiple organizations without per-tenant configuration.

Correct OIDC implementation requires applications to identify users using immutable claims. The subject (sub) claim is a pairwise identifier derived from a hash combination of the user's Object ID, the application ID, and the tenant ID -- guaranteed globally unique and immutable. The issuer (iss) claim contains the tenant ID. Neither can be modified by an attacker.

Vulnerable implementations use the email claim for user identification. This is dangerous because the mail attribute in Entra is mutable. An attacker with admin access to their own tenant can modify it via a simple Graph API PATCH operation:

No domain verification is required in the attacker's tenant. The attacker does not need to own victim-company.com. After setting the mail attribute, the attacker authenticates to the vulnerable SaaS application. The application receives an ID token with the spoofed email claim, matches it against the existing user record, and grants the attacker full access as the victim.

Microsoft's mitigations include:

• The removeUnverifiedEmailClaim attribute on app registrations, defaulting to true for apps created after June 2023. Older applications are not affected, and developers can set it to false.
• Verified domain checking: Entra tenants can verify domains via DNS TXT/MX records, and the mitigation prevents unverified domain emails from appearing in the email claim. But this only applies when the mitigation is active.

Bypass vectors remain: developers can explicitly set removeUnverifiedEmailClaim to false, applications created before June 2023 are grandfathered, and guest account conversions and hybrid Active Directory synchronization can also set unverified email addresses.

Woodruff advocates for Microsoft to remove the ability to send the email claim in ID tokens entirely, forcing applications to use the UserInfo endpoint (/oidc/v2.0/userinfo) for email addresses post-authentication, which would eliminate the attack surface.

Demo / Proof of Concept

▶ Watch: Vulnerable apps: HR platform with PII, O365 integrations enabling mail access (26:00)

Woodruff showed video demonstrations of: setting an unverified email address on a user (Kenny Rogers) in Graph Explorer via a PATCH operation, then verifying the change; and examining ID tokens via jwt.ms showing the spoofed email claim appearing in tokens from the attacker's tenant. The demonstrations used controlled accounts and did not target live vulnerable applications. He offered to show a full end-to-end exploitation video if time permitted.

Defensive Implications

▶ Watch: Detection is impossible: all customer defenses are bypassed (34:00)

The defensive picture for nOAuth is bleak for customers:

• Your conditional access, MFA, Defender for Cloud Apps, CASB, and SSPM are all bypassed. The attacker authenticates through their own tenant, not yours. All your Entra-level defenses protect your tenant, not the SaaS application.
• Log correlation is theoretically possible but practically infeasible. You would need to compare Entra sign-in logs with SaaS application sign-in logs, looking for logins in the SaaS app without corresponding Entra sign-ins in your tenant. No one is doing this at scale.
• Browser security extensions and push security tools do not detect this pattern.
• For application developers: Check your app registration for removeUnverifiedEmailClaim set to true. If your app was created before June 2023, this setting may not exist and defaults to allowing unverified email claims. Fix your user identification logic to use the sub or oid claims instead of email. Test your application -- the first vendor Woodruff worked with needed multiple iterations to fully remediate.
• For customers: Ask your SaaS vendors whether they use the email claim for user identification in their OIDC implementation. Request that Microsoft add an attribute to service principals indicating whether an application consumes unverified email claims.
• For Microsoft: Woodruff recommends flagging on service principals whether the application requests unverified email claims, giving customers visibility to make their own risk assessments. He also advocates removing the email claim from ID tokens entirely and directing developers to the UserInfo endpoint.

Key Takeaways

• The nOAuth vulnerability -- account takeover in SaaS applications via spoofed email claims in OIDC -- remains actively exploitable two years after being declared "fixed."
• Testing 104 Entra Gallery applications found 9 (8.6%) vulnerable, including HR platforms with PII and applications with Office 365 integrations enabling email/calendar access.
• The attack bypasses all customer-side Entra defenses: conditional access, MFA, CASB, SSPM, and browser security -- because the attacker authenticates through their own tenant.
• Microsoft characterizes this as a developer problem, leaving customers with no visibility into which SaaS applications are vulnerable.
• Detection is practically impossible for most organizations, making this a stealth attack vector for targeted compromise of SaaS-hosted data.
• Application developers must use immutable claims (sub, iss, oid) instead of email for user identification and rigorously test their OIDC implementations.

About the Speaker(s)

Eric Woodruff is Chief Identity Architect at Semperis, a company focused on Active Directory and identity security. He has deep expertise in Microsoft Entra ID, OIDC, and identity architecture. He is the owner of the domain entra.ms and maintains a blog where the full nOAuth research is published at entra.ms/noauth. He previously wrote about the original nOAuth disclosure in 2023, criticizing the media coverage for suggesting the issue was fixed when it was not. He also presented this research at Troopers conference the week prior.