Key findings
- In testing 38 additional applications since our initial research, Semperis found 2 that were vulnerable to nOAuth abuse. We have reported our findings for those two applications to the software vendors.
- One of the vulnerable applications had permissions that would enable an attacker to pivot back into Microsoft 365, reinforcing that nOAuth can endanger not only data in the SaaS application but also an organization’s Microsoft 365 estate.
- In our latest case with Microsoft Security Response Center, MSRC has rated this vulnerability as moderate. However, Semperis stands by our rating of SEVERE. nOAuth is still difficult for customers of vulnerable applications to detect and impossible for customers of vulnerable applications to defend against. The abuse is publicly documented and is of low complexity once a vulnerable application is found.
This article is a follow-up to our original research on nOAuth. Although it feels like just yesterday that we released those findings at TROOPERS25 and at fwd:cloudsec 2025, our research started back in the fall of 2024.
Performing additional nOAuth research six months after our original talk and then again a year after our initial research, we’ve found that the risk of nOAuth abuse still exists and that many organizations are still unaware of this vulnerability.
During October and November 2025, we tested 38 additional applications for the nOAuth abuse and found 2 that were vulnerable. During our previous research, we tested 104 applications and found 9 vulnerable. That means that as a cumulative percentage, roughly 8% of available apps are vulnerable to nOAuth.
Understanding how SaaS apps integrate with Microsoft 365
Microsoft Graph API is the unified API for accessing everything Microsoft 365: Exchange Online, SharePoint, OneDrive, and most other Microsoft 365 services. Third-party SaaS applications that want to integrate with these services request access to Microsoft Graph so that they can interact with users’ data or services on their behalf.
One example is Calendly, which asks for permissions to a user’s calendar so that it can manage their meeting appointments in Office 365 (Figure 1). For clarity, Calendly is not vulnerable to nOAuth. We are simply using it as a reference application to help you understand common behavior of SaaS applications.
When a user accesses the application, so long as the permissions have been consented to, the SaaS application receives an OAuth 2.0 access token from Entra ID. The application then uses that access token with Microsoft Graph API to access the service. In this example, the access token provided to Calendly has Calendar.ReadWrite and Calendar.ReadWrite.Shared permissions.
In many scenarios, the SaaS application also receives a refresh token (Figure 2). This token enables the SaaS application to maintain access to the user’s data, even if the user is not actively using the application.
Why do SaaS applications need this sort of access? In our example, this access enables Calendly to book client appointments on your calendar, even if you aren’t actively using the app. This way, the SaaS application can keep doing “stuff” with your data behind the scenes.
This is great for productivity, and there is nothing inherently wrong with the requested permissions. But when those permissions are combined with vulnerability to nOAuth, the stage is set for attackers to abuse the app—and potentially, to pivot back into Microsoft 365.
The difference between authentication and authorization
To fully understand how nOAuth can facilitate pivoting back into Microsoft 365, you need to know that OpenID Connect (OIDC) facilitates authentication with an ID token, and OAuth 2.0 facilitates authorization with an access token. When a refresh token accompanies an access token, the SaaS application can obtain new access tokens regardless of whether the user is authenticated.
Putting identity language nuances aside, OIDC facilitates a user signing in to an application. OAuth 2.0 facilitates the permissions that an application has to a user’s data. A refresh token enables the application’s access to the user’s data, even if the user isn’t signed in (Figure 3).
When a user first accesses an application, authentication and authorization might occur: The application might receive an ID token for the user and an access token so that the app can access Microsoft 365 resources. To the end user, this process is generally transparent, except when the application has never been used and consent is needed.
Plenty of frameworks and libraries for managing tokens exist, but ultimately the SaaS application developer determines how tokens are managed.
When a user subsequently authenticates, the application may (or may not) attempt to request a new access and refresh token, if the existing tokens are still valid. Because authentication and authorization are essentially treated as different functions, this disconnect between the two flows enables attackers to pivot.
Abusing nOAuth for the pivot to Microsoft 365
During our initial research, we discovered a vulnerable application that had integrations with Microsoft 365 with Calendars.ReadWrite.Shared permissions. Per Microsoft documentation, this integration:
Allows the app to create, read, update and delete events in all calendars in the organization user has permissions to access. This includes delegate and shared calendars.
Concerning, but not something that would enable an attack such as business email compromise (BEC).
This time around, we found a much broader and concerning permission set (Figure 4):
- Calendars.ReadWrite
- Mail.Send
- Contacts.ReadWrite
- Mail.ReadWrite
- offline_access
As mentioned earlier, these permissions are concerning because they enable an attacker not only to compromise the user within the SaaS application, but also to use the app interface to pivot back into Microsoft 365.
Recall that authentication and authorization are different functions with different tokens. The attacker essentially gains control over the users’ access in Microsoft 365 via those access and refresh tokens managed within the SaaS application (Figure 5).
In the vulnerable SaaS application, this behavior manifests as the ability for an attacker to send email as the compromised user (Figure 6).
Because the email is from a legitimate user in the tenant, the attacker now has an effective way to act as the compromised user within Exchange Online (Figure 7).
The attacker doesn’t have direct access to the access token, so the SaaS application’s UI determines how they can interact with Microsoft 365 resources. Still, these findings reinforce our longstanding concerns with nOAuth and the potential data access and lateral paths it can enable.
Researching nOAuth is like trying to prove a negative
When we published our findings in June 2025, the most common questions we received were how many total applications could be vulnerable. This is understandable, as indefinite numbers don’t make good headlines.
However, it was—and still is—impossible to quantify how many applications might be vulnerable. A search for the number of existing SaaS applications returns a number anywhere from 70,000 to more than 300,000. The Microsoft 365 Defenders Cloud app catalog lists 36,932 SaaS applications, but not all of them integrate with Entra ID for authentication.
No matter how you run the numbers, it’s going to be guesswork. At the low end, if 50% of all applications use Entra ID for authentication, then testing 142 (out of 35,000) applications puts us at 0.4% tested. At the high end (of 150,000 apps), it would put us at 0.098% tested.
At Troopers, I stated that we found nine vulnerable applications, and I doubt that we found 90% of all vulnerable apps. Now, with our new discoveries, I doubt 11 is the total of vulnerable applications out there. It’s just impossible to know.
Microsoft would know how many applications are configured with removeUnverifiedEmailClaim set to false and how many apps are grandfathered in to use this claim. But that doesn’t indicate whether the application is vulnerable.
On the topic of permissions, while we only found abuses of applications that have Exchange Online integrations, integrations with SharePoint and OneDrive are equally popular. It would be naïve to believe that only a certain percentage of applications with these integrations are vulnerable to nOAuth. There are hundreds of other Microsoft Graph permissions, many of which would be highly concerning if an attacker got their hands on them. In fact, doing so is the main goal of another very common attack: Illicit Consent Grants.
Timeline and MSRC response
- November 18, 2025: With new findings specific to Microsoft 365 and this ability to pivot back in, we opened a case with MSRC. We provided full details of the findings, written and in a video showing the attack against our test user. We also asked MSRC to sunset the ability to send an unverified email claim. As we discuss in our original post, there are other ways to receive the email claim.
- December 3, 2025: MSRC replied that the case is considered moderate risk and closed the case on. In its response, MSRC stated the following:
After careful investigation, we have assessed this case with moderate severity vulnerability. Our respective product/service teams have been notified about this and they may work on adding further defense-in-depth mechanisms, as needed, in future releases.
As a result, we are closing this case.
Why nOAuth still matters
We’ll keep researching nOAuth vulnerable applications and advocating for change at Microsoft, for multiple reasons:
- nOAuth abuse is publicly documented.
- Research has proven access to sensitive information in platforms such as Human Resource Management Systems (HRMS).
- Research has proven that potential paths of lateral movement exist to move back into Microsoft 365.
- Customers of vulnerable applications have no defense against nOAuth.
- Security researchers have proven that determining customers of SaaS applications is relatively easy.
- Using platforms like LinkedIn to target privileged users of SaaS applications and deduce their email addresses is also simple.
Semperis snapshot
Although enterprise organizations don’t have strong defenses against nOAuth, it’s important to understand the risk relative to your data. Before onboarding a new SaaS application, ask the vendor if it knows about the nOAuth research and refer the vendor to our blogs.
For vendors and developers, following OpenID Connect specifications from Microsoft is critical to ensure your application is not vulnerable to nOAuth. For further details, refer to our previous research.
Related resources
• nOAuth Abuse Alert: Full Account Takeover of Entra Cross-Tenant SaaS Applications
• nOAuth on-demand session (TROOPERS25)
