nOAuth Abuse Alert: Full Account Takeover of Entra Cross-Tenant SaaS Applications

Principales resultados

• In testing 104 applications, Semperis found 9 (or roughly 9%) that were vulnerable to nOAuth abuse.
• As the abuse has been already disclosed, the ability to perform nOAuth is low complexity.
• nOAuth abuse exploits cross-tenant vulnerabilities and can lead to SaaS application data exfiltration, persistence, and lateral movement.
• The abuse is difficult for customers of vulnerable applications to detect and impossible for customers of vulnerable applications to defend against.
• Semperis researchers rate this vulnerability as potentially SEVERE due to the attack’s low complexity and difficulty of detection and defense.

The nOAuth vulnerability exposes a critical authentication flaw in vulnerable software-as-a-service (SaaS) applications. With only access to an Entra tenant—a low barrier—and the target user’s email address, an attacker can take over that user’s account in the vulnerable application. From there, the attacker can access all the data that the target has access to within that application.

We promptly reported our findings to the application vendors and the Microsoft Security Response Center (MSRC) in December 2024; MSRC acknowledged receipt of the report and opened case 93209. In March 2025, we notified MSRC of our intent to disclose. MSRC closed the case in April 2025. Through May and June of 2025, we continued to contact application vendors that were vulnerable and shared the details with MSRC. In June 2025, we received feedback from MSRC reiterating that vendors should follow recommendations, and vendors who do not are subject to removal from the Entra App Gallery.

Detecting an attack that abuses nOAuth is difficult to impossible. No remediation or mitigation options are available to customers, other than asking for application vendors for updates to render applications invulnerable to nOAuth abuse. Due to the simplicity of this abuse, the complexity of detection, and the existence of actively vulnerable applications, Semperis considers this vulnerability to be a severe risk for Entra ID customers.

This article details the Semperis Security Research Team’s exploration of nOAuth, focused on applications in the Microsoft Entra App Gallery. We discovered nine vulnerable applications, including those that might hold personally identifiable information (PII).

What is nOAuth?

On June 20, 2023, Omer Cohen of Descope published the disclosure “nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover.” The fundamental problem that leads to nOAuth is app developers’ use of anti-patterns relative to the implementation of OpenID Connect (OIDC). These anti-patterns include the use of mutable attributes, such as an email address, for user identifiers. Because Entra ID permits users to have an unverified email address, the use of this attribute enables user impersonation across tenant boundaries. In the Descope disclosure, they described that the attack sits in a “grey area” in Entra ID, due to the dependency of developers following anti-patterns. While we agree with this, it leaves the mutual customers of Microsoft and the SaaS app vendor (ISV) vulnerable to this abuse.

In response to Cohen’s discovery, MSRC published an article on nOAuth risks: “Potential Risk of Privilege Escalation in Azure AD Applications.” As part of Microsoft’s customer impact statement, this article stated:

Microsoft has identified several multi-tenant applications with users that use an email address with an unverified domain owner. Although unverified email addresses do not pose a risk to applications that do not utilize email claims for authorization purposes, these application owners have been notified and were provided with guidance on how to modify their applications, if applicable. If you did not receive a notification, your application has not consumed email claims with unverified domain owners. To protect customers and applications that may be vulnerable to privilege escalation, Microsoft has deployed mitigations to omit token claims from unverified domain owners for most applications.

Microsoft customer impact statement

Microsoft also published specific guidance on migrating away from using email claims. At the time of writing, that article guidance is no longer available on the Microsoft site, although you can find an archived version elsewhere.

How does nOAuth abuse work?

nOAuth abuse requires three components:

• The ability to set an unverified email address in Entra ID
• An App registration that permits the unverified email claim
• Vulnerability of an application to this combination

Let’s run through an example of what this type of abuse might look like.

Setting an unverified email address in Entra ID

Entra ID and Microsoft 365 services include a default tenant with an onmicrosoft.com domain name, such as contoso.onmicrosoft.com. As organizations configure their deployments and onboard their own domain names for services, the verification process uses a TXT or MX record to verify domain ownership. Once verified, the domain name is marked as such in Entra ID (Figure 1).

To support guest user functionality in Entra ID, however, the domain suffix of the email attribute does not need to be a verified domain. Therefore, any user in any Entra tenant can have any email address in the mail attribute.

For example, Figure 2 shows a user, Adele Vance, whose mail attribute has the same value as the userPrincipalName attribute.

We can run a simple PATCH to change this mail attribute (Figure 3).

Another GET shows that Adele now has an email address for a domain that is not verified within this tenant (Figure 4).

Verifying an email address change

If we want to validate the unverified email address as a claim in an ID token, we can configure an app registration in Entra ID with a Redirect URI of https://jwt.ms and pass the ID token along to it.

For app registrations created after June 2023, by default the unverified email claim is not emitted by Entra ID. To modify the configuration to permit this, we can use a simple PATCH on the authenticationBehavior for the app registration, setting removeUnverifiedEmailClaim to false (Figure 5). This process is documented by Microsoft in the article “Manage application authenticationBehaviors.”

Once our app registration is configured, we can use it to replicate the behavior of a vulnerable application and view the ID token (Figure 6).

If this ID token is consumed by an application that uses the email claim as the unique identifier, the application won’t know that the user is not, in fact, the legitimate user.

Mitigating nOAuth abuse

As noted, mitigation of nOAuth abuse ultimately requires the developer to properly implement authentication to ensure a unique, immutable identifier.

Pam Dingle, Director of Identity Standards at Microsoft, published an article shortly after the disclosure of nOAuth on developer anti-patterns. It’s worth a read: “The False Identifier Anti-pattern.”

As Pam highlights in the article, per the OpenID Connect specification, under Section 5.7, a combination of the issuer (iss) and subject (sub) claims is the only way an application (SP) can ensure a unique and stable user identifier.

In Entra ID, the issuer (iss) is emitted as an Issuer URI that includes the tenant ID, which is globally unique (Figure 7).

The subject (sub) is a pairwise identifier that is unique to each user for each application ID (Figure 8). Just as important, sub is an immutable value in Entra ID. Entra ID does not permit any sort of claims transform or modification on the subject claim, ensuring its uniqueness.

Details on the claims within an ID token issues by Entra ID can be found here: “ID token claims reference.”

Microsoft changes to mitigate nOAuth abuse

Within Entra ID, Microsoft made changes so that any app registration created after June 2023 will not, by default, emit an email claim if the email address is unverified. Of course, thousands upon thousands of SaaS applications have been in existence since before June 2023, and many developers still want and need to consume the email address; many SaaS applications want to send email to end users, and consumption through a claim is the easiest way to get that information.

To help developers, Microsoft also introduced the xms_edov optional claim, which a developer can use to determine whether an email address is verified. Upon writing this article, though, the xms_edov claim seems to be in a state of uncertainty, which makes one wonder if it’s being deprecated. Although Microsoft documents indicate that the claim is optional, it is no longer available in the UI for setting optional claims. Setting xms_edov as an optional claim through Graph API works, but you are met with a message afterwards that it is not a valid optional claim (Figure 9).

In action, a dev could use this information to decide whether a user’s email address is verified in the tenant (Figure 10).

Semperis’ new nOAuth abuse research

The Descope focus

In the research published by Descope, the focus is on SaaS applications that have support for multiple identity providers, such as Google and Microsoft, Facebook, and so on (Figure 11).

For usability purposes, SaaS applications typically have account-merge logic. For example, if I sign up for Medium with a Facebook account, and then later sign in with my Google account, the two authentication sources ultimately take me the same Medium account.

The problem that Descope explored was that, because any user account in Entra ID could carry the email claim, developers who were merging based on email could unknowingly let an attacker into a target user’s account.

Beyond some of the capabilities that Microsoft has implemented, Descope recommended that SaaS applications that support account-merging functionality interrupt the flow the first time a sign-in is attempted with a different account source, using a function to validate email ownership. We agree with this advice. This function can take the form of an email magic link, where the user receives an email asking them to verify ownership before the merge takes place.

In our own research, we witnessed this as a common security practice among apps that proved invulnerable to nOAuth abuse.

Semperis research

In the late fall of 2024, as part of some exploratory research, we were reviewing the research performed by Descope and decided to test it out against some SaaS applications. This coincided with an idea to explore the Microsoft Entra App Gallery. The Entra App Gallery is a portal within Entra ID that Microsoft manages and allows third-party SaaS vendors to essentially surface applications that integrate with Entra ID (Figure 12).

In our research, we examined all 1,017 OIDC integrations available at that time and found 104 applications that permitted self-sign up for the application. As the SaaS market is heavily competitive, vendors tend to allow either free tiers or trials of their applications with little friction, allowing you to use and test the application without needing to go through any sales channels. We focused on these applications not only because they provided a low barrier for security research, but also so that we would stay within the boundaries of ethical testing.

In each application that we tested, we used a “victim” tenant that we managed to configure an account that we owned within the platform. We then used a different tenant, the “attacker” tenant, to attempt nOAuth abuse against our own victim. This way, we ensured that our testing affected only accounts under our control and only accessed test data samples that we created.

Our research differs from Descope’s in that we were interested in finding applications that permitted Entra ID cross-tenant nOAuth abuse. Essentially, the target (victim) customer is a Microsoft customer with an Entra ID tenant, and the attacker uses a different Entra ID tenant to perform the abuse. The following diagram from Descope is valid as far as the attack flow in our research (Figure 13).

However, with our focus, the SaaS application only needs to support Entra ID for authentication. Although almost all the SaaS applications we tested supported a local user account, we found that some applications also supported multiple identity providers, such as Google and Entra ID, whereas others supported only Entra ID.

Further, we theorized that if an application supported only Entra ID for authentication, it was unlikely that the developer implemented the account-merging logic and email verification that Descope noted, as the developer likely did not expect an account-collision scenario.

Vulnerable applications

In testing of 104 applications, we found 9 that were vulnerable to nOAuth abuse; this translates to vulnerability in roughly 9% of tested applications. As 104 is only a drop in the bucket of SaaS applications out there that are integrated with Entra ID, you can extrapolate these numbers against the tens of thousands of available SaaS applications.

Of the applications we found vulnerable, we noted some interesting observations regarding size, scale, and application type. We found a human resources management system (HRMS) platform that, in practice, would likely be filled with PII. Likewise, we found applications that integrated back into Microsoft 365 for tasks such as mail and calendar access. As these integrations used a different set of access and refresh token combinations, an attacker that successfully abuses nOAuth would be able not only to gain access to the SaaS application data, but also potentially to pivot into Microsoft 365 resources.

Unfortunately, testing at scale is time consuming. Beyond configuring the Entra tenant to perform the abuse, we needed a set of human eyes on the interface of the SaaS application to determine whether the attacker was able to gain access to the victim’s account. Although most applications that were invulnerable to this abuse generally presented a new onboarding flow into the application, some simply dropped us into the app’s main screen, requiring us to examine account information or attempt to manipulate data within the application to determine whether the attacker was in the same account as the victim.

Contacting stakeholders

As a result of this research, we opened a case with MSRC. We also attempted to determine the stakeholders at each ISV that had a vulnerable application. After contacting these stakeholders, following Semperis’ principle of being a Force for Good, we offered to help them resolve the vulnerability in their application; a few vendors took us up on that offer. In these cases, we helped the vendors understand the problem and performed additional testing of nOAuth abuse against their application until the issue was resolved.

Customer defense: a lack of options

Ultimately, the only defense a customer has against nOAuth abuse is 1) urging the vendor to fix the issue or 2) abandoning the SaaS application.

Because the attack happens outside of the victim’s purview, traditional defense mechanisms cannot provide protection. These include:

• Multifactor authentication (MFA) and authentication strength enforcements in Entra ID
• Conditional access
• Zero Trust Network Access (ZTNA) and Cybersecurity for Any Business (CASB) solutions
• Endpoint detection and response (EDR)
• Extended detection and response (XDR)

nOAuth abuse detection

Although (SaaS Security Posture Management (SSPM) solutions can provide some insight into SaaS applications, they generally focus on the configuration and security posture that is exposed to customers of the platform and are not likely to indicate nOAuth abuse. Similar problems exist with enterprise secure-browser platforms and browser plug-ins, which can help highlight other backdoors into SaaS applications but are unlikely to surface this type of attack.

Unfortunately, this leaves few options for customers:

• SaaS authentication log correlation with Entra ID within a SIEM platform
• Asking their vendors about nOAuth
• Performing nOAuth abuse testing themselves

From an Entra ID perspective, we examined service principals of multi-tenant applications and found no attributes exposed to a customer that would indicate that the application consumes unverified email claims. Even if such attributes existed, there would be no way to indicate what the application uses this claim for.

Authentication log correlation

To use log correlation to detect nOAuth abuse, you would need to consume your Entra ID authentication logs into a security information and event management (SIEM) solution, such as Microsoft Sentinel. You would also need to consume authentication logs from your SaaS application and then correlate the two logs within the SIEM. You would need to look for authentication events in the SaaS platform with a missing authentication event in Entra ID (Figure 14).

Of course, the results of putting this theory into practice will vary widely. Although subject (sub) is the key identifier in the SaaS application, this value is not captured in Entra ID sign-in logs when authenticating. Therefore, the SaaS application would also need to contain attributes like UPN or email address within its logs for correlation. Likewise, the SaaS vendor authentication logs need to be available in a way that can be consumed by a SIEM. Other factors, such as time drift and precision, can compound the difficulty of detecting nOAuth abuse through log correlation.

Testing for nOAuth and vendor responsibility

A customer’s only other option would be to test the SaaS applications they consume for nOAuth abuse. Before doing so, they can reach out to the app vendor to ask whether the vendor knows of nOAuth and has tested against nOAuth abuse.

A few items to note:

• Certifications such as SOC II have not investigated this abuse. We found vulnerable apps whose vendors had SOC II and other certifications listed on their sites.
• Ask the vendor specifically whether they have tested against this vulnerability. We found vendors who believed they had resolved the issue, yet we were still able to perform nOAuth abuse against their apps.

If the vendor cannot definitively answer this question, the customer can perform this test against any application of concern. Just like security researchers, customers should ensure that they are testing within ethical boundaries: testing against their own user accounts and understanding any contractual requirements they might have with the vendor.

Software developer defense against nOAuth

Developers that consume the email claim should verify that they are not using it for user identification. If they are, they should go through the steps documented by Microsoft for following OIC specifications, using issuer and subject.

Developers can also examine their app registrations to determine whether they are receiving the unverified email claim. However, it is up to the developer to examine their code to determine how the email claim is used.

Alternative solutions also exist for receiving the email attribute data other than from a claim in the ID token. OIDC specifies a UserInfo endpoint, which is implemented within Entra ID. This endpoint can be used to receive information about the authenticated user. By calling the UserInfo endpoint, the application can obtain the user’s email address after authentication, even if that address is not verified. This step ensures that the email claim is not used as the unique identifier of the user.

In this example, we can call the UserInfo endpoint on Adele Vance, who has an unverified email address (Figure 15). The subject, which is the unique identifier, will match the one in the ID token.

Developers who have updated their code to resolve the nOAuth vulnerability should test their application post-fix to ensure that it is not vulnerable to nOAuth abuse. In our remediation work with vendors, the initial fix did not always resolve the vulnerability.

When communicating with MSRC on our findings, it reiterated that developers need to follow recommendations and referred us to the article it published from the disclosure in 2023. As there are legitimate needs for applications to obtain a user’s email address, there is no way to determine whether an application is properly using the attribute without testing each application. As we’ve noted in our own testing, this is a very time-consuming process.

MSRC also said that it has communicated with application vendors, and that those that have not fixed their applications are subject to removal from the Entra App Gallery.

Divulgación y calendario

Surprised to find nOAuth abuse working, especially in applications published in the Entra Gallery, we opened a case with MSRC (assigned case number 93209).

We also urged the Microsoft Identity Product Group to be more aggressive in protecting customers, considering the difficulty of nOAuth abuse detection. We suggested warning customers of service principals that the application permits unverified email claims, even though, as we have noted, it would not be an absolute identifier of being vulnerable to nOAuth.

We also indicated the nine vulnerable applications we found, in case MSRC was in contact with those vendors.

• December 3, 2024: Case created with MSRC
• December 3, 2024: Case acknowledged by MSRC
• December 4, 2024: We provided additional case details to MSRC
• December 17, 2024: We updated the case with MSRC, noting that we worked with a vendor to resolve one of the vulnerable applications
• March 17, 2025: We asked MSRC about case status; no response received
• March 18, 2025: We notified MSRC in portal about intention to disclose in session at Troopers 2025 (if selected)
• March 19, 2025: We notified MSRC in email about intention to disclose in session at Troopers (if selected) and asked for guidance on disclosure, as the original vulnerability had already been disclosed; no response received
• April 18, 2025: Case was closed by MSRC, stating that “a fix was reported for the issue you presented” without further information
• April – May 2025: We tested and found application vendors that were vulnerable to nOAuth; we notified the vendors again and reached out to MSRC with our findings
• June 2025: MSRC provided details regarding applications vulnerable to nOAuth in the Entra Application Gallery
• June 26, 2025: Public disclosure