TL;DR
nOAuth is a critical misconfiguration where applications use the unverified email claim from Microsoft Entra ID tokens to identify users, allowing attackers to fully take over an account by simply creating a new tenant with a matching email address. The fix requires switching user identification to the immutable `sub` and `iss` claims, restricting multi-tenant access, and continuously monitoring identity changes across hybrid environments.
An attacker doesn’t need your password or your token. With nOAuth, they just need your email address and a misconfiguration in how your app trusts Microsoft Entra ID (formerly Azure AD) during OAuth 2.0 authentication. That’s enough for full account takeover. The flaw comes down to applications using the wrong claim from Azure AD tokens to identify users. It’s shockingly common, and it’s easy to exploit.
This article covers exactly how nOAuth works, walks through the attack step by step, and gives you concrete fixes you can apply today. If your app relies on Entra ID for sign-in or you’re responsible for securing identity infrastructure in a Microsoft environment, you’ll want to read on.
Before getting into the technical mechanics, let’s be clear about one thing: nOAuth isn’t some obscure edge case. It’s a widespread authentication flaw that affects how applications trust identity tokens from Microsoft Entra ID. If your organization runs multi-tenant apps or consumes third-party SaaS products that authenticate through Entra ID, you’re potentially exposed right now.
The name tends to trip people up. nOAuth sounds like it could be a library, an authentication standard, or maybe a competitor to OAuth, but it’s none of those. nOAuth is a label for a specific misconfiguration: an implementation flaw in how applications handle identity claims during OAuth 2.0 and OpenID Connect authentication with Entra ID. It’s a dangerous pattern that developers fall into when building sign-in flows against Entra ID’s multi-tenant OAuth endpoints.
The core issue is applications treating unverified email claims inside ID tokens as reliable user identifiers. nOAuth is a real, exploitable weakness that bypasses MFA, conditional access policies, and zero-trust controls entirely. If you’ve ever dealt with security misconfigurations in Office 365 environments, this pattern will feel uncomfortably familiar, except the stakes here are even higher.
The flaw was originally detected in June 2023 by Descope during cross-tenant testing of Entra ID multi-tenant OAuth applications. Researchers found that an attacker who controlled any Entra ID tenant could craft tokens containing a victim’s email address and use those tokens to authenticate as that victim on vulnerable applications.
What makes nOAuth especially concerning is how long it has persisted. According to Infosecurity Magazine, at least 15,000 SaaS applications were still likely vulnerable to nOAuth as of June 2025, two full years after the initial discovery. Many SaaS vendors simply don’t know what to look for, which means enterprise customers relying on those applications have no way to detect or block the attack on their own.
That gap between discovery and remediation is exactly why nOAuth demands attention from every IT team managing Entra ID–integrated applications. If your organization relies on Office 365 security features as part of your defense strategy, understand that those controls won’t catch this because the vulnerability lives in how the application itself processes the token, not in Entra ID’s authentication pipeline.
To understand why nOAuth is so dangerous, you need a solid grasp of how OAuth 2.0 and OpenID Connect actually function and where the handoff between “authorization” and “authentication” creates room for mistakes. Let’s walk through both protocols and then pinpoint exactly where things break down.
OAuth 2.0, at its core, is an authorization framework. It was designed to let one application access resources in another application on behalf of a user without that user handing over their password. As WorkOS explains in their complete guide to OAuth 2.0, the protocol defines specific roles:
The user grants consent, the authorization server issues an access token, and the client uses that token to call APIs. OAuth 2.0 was never meant to tell the application who the user is.
That’s where OpenID Connect steps in. OIDC is an authentication layer built directly on top of OAuth 2.0. It adds a JSON Web Token that contains claims about the authenticated user: their unique subject identifier (the sub claim), the issuer, the audience, and sometimes optional fields like email or name. The ID token is what tells your app: “This person is John Smith, and he authenticated successfully through this identity provider.” Without OIDC, OAuth alone can’t confirm identity. With OIDC, you get both authorization and authentication in a single flow.
The following table breaks down how OAuth 2.0 and OpenID Connect differ across several important dimensions and why those differences matter when it comes to the nOAuth flaw.
Aspect | OAuth 2.0 | OpenID Connect (OIDC) |
Purpose | Authorization: granting access to resources | Authentication: verifying user identity |
Token issued | Access token | ID token (JWT) + access token |
User identity info | Not included | Included via claims (sub, email, name, etc.) |
Primary claim for user identification | n/a | Sub (subject): immutable and unique per tenant |
Relevance to nOAuth | Provides the flow that nOAuth exploits | Contains the claims that nOAuth abuses |
Here’s the problem. The OIDC ID token contains multiple claims, and not all of them carry the same level of trust. The sub claim is the immutable, unique identifier for a user within a given tenant: It never changes, and it can’t be set by an end user. The email claim, on the other hand, is a different story entirely. In a multi-tenant Entra ID configuration, an attacker who controls their own tenant can assign any email address to any account they create. That email address then shows up in the ID token as if it’s verified, and there’s nothing about the token’s structure that flags this as suspicious.
When an application uses the email claim instead of sub to match an incoming token to an existing user account, it has no way to distinguish a legitimate sign-in from a forged one. The token is structurally valid, it’s signed by Entra ID, and it passes standard signature verification. The nOAuth flaw lives entirely in this trust decision: The app chose the wrong field. It’s a logic error, not a cryptographic one, which is precisely why it slips past every security layer that inspects token integrity rather than claim semantics. This kind of misconfiguration is especially concerning for organizations managing user provisioning across hybrid Active Directory and Office 365 environments, where identity data flows between multiple systems and a single incorrect trust assumption can cascade across the entire infrastructure.
Now that you have a clear picture of how OAuth 2.0 and OIDC divide the work of authorization and authentication, let’s look at the specific mechanics that turn this architecture into an attack surface.
The entire nOAuth vulnerability comes down to the flawed assumption that the email claim inside an Entra ID token is a trustworthy, unique identifier for a user. It’s not. In a multi-tenant Entra ID setup, any tenant administrator can create a user account and assign whatever email address they want to it. There’s no cross-tenant verification that the person actually owns that email. So if your app reads the email claim from the ID token and uses it to look up an existing user in your database, an attacker from a completely different tenant can impersonate anyone just by setting the right email on a throwaway account.
Now compare that with the sub claim: it’s an immutable, tenant-scoped identifier assigned by Entra ID itself. No admin can forge it. No user can change it. As Okta’s ID token validation guide makes clear, proper token verification requires checking the iss, aud, and sub claims, not optional fields like email that carry no integrity guarantee across trust boundaries. Applications that skip this step and rely on the email field are essentially handing an attacker the keys to choose which account they want to take over.
Here’s exactly how a nOAuth attack unfolds from start to finish. Each step builds on the last, and understanding the full chain makes it much easier to see where your defenses need to sit:
Following the correct validation path (matching on sub plus iss instead of email) breaks every step of this chain after step two.
Don’t let the simplicity of this attack fool you into underestimating its impact. A successful nOAuth exploit gives the attacker full account-level access to whatever the victim can do inside the application. That could mean reading sensitive documents, exfiltrating customer data, modifying configurations, or escalating privileges further into connected systems. And because the authentication token is cryptographically valid, there’s no anomaly for your SIEM to flag and no failed login attempt to trigger an alert. MFA doesn’t help either because the attacker authenticates legitimately against their own tenant. The nOAuth flaw bypasses identity controls entirely because the weakness sits in the application’s claim-handling logic, not in the identity provider’s security mechanisms.
Understanding how nOAuth works gets you halfway there. The rest comes down to making sure your environment isn’t exposed and that you’ll know quickly if something goes wrong.
Fixing nOAuth means changing what your application trusts inside the ID token. If your app is matching users based on the email claim, that’s the root of the problem, and the fix is straightforward once you know where to look. Here’s a step-by-step remediation path:
The nOAuth flaw is a sharp reminder that authentication logic carries zero margin for error. One wrong claim selection doesn’t just introduce a bug; it opens a direct account takeover path that sidesteps every perimeter control you’ve built.
That’s the uncomfortable truth about identity security: Your infrastructure can be locked down perfectly, but a single trust assumption in application code can undo all of it. Organizations that have already experienced data breach patterns tied to credential misuse know how quickly these gaps get exploited once discovered.
nOAuth bypasses MFA, conditional access, and zero-trust controls because the weakness sits in the application’s claim-handling logic, not the identity provider.
Fixing vulnerable code is essential, but you also need visibility into what’s happening across your identity infrastructure right now. Cayosoft Guardian Protector provides real-time change monitoring across Active Directory, Entra ID, Microsoft 365, Teams, Exchange Online, and Intune, capturing who changed what, when, and from where. Unlike static scanners that only show you a point-in-time snapshot, Guardian Protector continuously tracks privilege escalations, policy modifications, and suspicious account changes the moment they occur. It’s agentless, free to start, and covers unlimited identity objects with no hidden caps.
No single tool addresses every angle of nOAuth risk. The table below breaks down how common detection approaches compare, so you can see where each one fits and where the gaps remain.
Approach | Detects nOAuth Code Flaw | Monitors Identity Changes in Real Time | Covers Hybrid Environments |
Code audit / penetration test | Yes | No | No |
Static AD scanners | No | No | Partial |
SIEM log ingestion | No | Delayed | Partial |
Cayosoft Guardian Protector | No (app-layer issue) | Yes (continuous) | Yes (full hybrid coverage) |
Code audits fix the root cause; continuous identity monitoring catches the fallout if an exploit succeeds. Together, they close the gap. Download Guardian Protector to get real-time hybrid identity visibility at no cost.
The nOAuth flaw destroys a comfortable assumption: that a valid, signed token from a trusted identity provider automatically means the right person is at the door. It doesn’t. If your application latches onto the wrong claim to identify users, every other security investment (MFA, conditional access, network segmentation, etc.) becomes irrelevant to that specific attack path. The fix itself is straightforward, but tracking down every place the vulnerability lurks across your application portfolio demands deliberate effort and honest auditing.
Start with the code. Audit every application integrated with Entra ID for email-based user matching, switch to sub plus iss, and test the change against a secondary tenant before you consider it resolved. Then make sure you have continuous visibility into identity changes across your hybrid environment, so if something slips through, you catch it in seconds rather than months.
No, because the attacker authenticates legitimately against their own Entra ID tenant using their own credentials and MFA. The vulnerability exists in how the application processes token claims after authentication has already succeeded.
Applications should use the sub (subject) claim combined with the iss (issuer) claim. The sub claim is immutable, unique per tenant, and cannot be set or modified by tenant administrators.
Single-tenant applications are far less exposed because they only accept tokens from one specific Entra ID tenant, which prevents an attacker from authenticating with a token issued by a separate malicious tenant. However, using the sub claim for user identification is still a best practice regardless of tenancy configuration.
Create a separate Entra ID tenant, set up a user account with an email address matching an existing user in your application, then attempt to sign in. If your app grants access to the original user’s account, the vulnerability is confirmed.
Many developers default to the email field because it is human-readable and appears to be a natural unique identifier, and Microsoft’s own documentation has not always emphasized the risks clearly enough. The sub claim is an opaque string that requires more deliberate mapping logic, which leads teams to take the simpler but less secure shortcut.
Cayosoft is recognized by Gartner as an ITDR solution provider and provides solutions that make identities more resilient to attacks and guarantee a fast forest recovery, if needed. Learn how Cayosoft Guardian facilitates granular change tracking, post-breach analysis, and long-term AD security improvements. Schedule a demo to see the capabilities in depth.