nOAuth abuse exposes a cross-tenant account takeover gap

At a glance

What this is: Semperis reports that nOAuth abuse can let attackers take over SaaS accounts across tenants by exploiting applications that use mutable email claims for identity.

Why it matters: This matters because it breaks the normal trust model for Entra-connected SaaS, forcing IAM, NHI, and lifecycle teams to treat identity binding, token claims, and vendor testing as governance issues, not just app bugs.

By the numbers:

• In testing 104 applications, Semperis found 9, or roughly 9%, that were vulnerable to nOAuth abuse.

👉 Read Semperis's analysis of nOAuth abuse in Entra-connected SaaS

Context

nOAuth abuse is a cross-tenant account takeover pattern in which a SaaS application mistakes a mutable email attribute for a stable identity. In practice, that means an attacker can use a low-friction Entra tenant and a target email address to impersonate the user inside a vulnerable application.

The IAM problem is not limited to one vendor stack. Any programme that lets application logic treat email as a unique identifier is depending on a claim that can change, be unverified, or be reused across tenants. That creates a governance gap across SaaS, federation, and access review processes, not just a coding defect.

The article’s findings are typical of a broader authentication anti-pattern: convenience-driven account matching built on data that was never meant to prove identity. That makes detection difficult for customers and remediation dependent on the software owner, not the tenant administrator.

Key questions

Q: How should security teams prevent cross-tenant account takeover in SaaS apps?

A: Security teams should require stable identity binding, usually issuer plus subject, and forbid account linking based on mutable attributes such as email. They should also verify that the application proves ownership before merging identities from different providers. Where the vendor cannot demonstrate this, treat the app as unsafe for identity-based access decisions.

Q: Why do email claims create identity risk in federated SaaS environments?

A: Email claims are risky because they are useful for contact and lookup but are not stable proof of identity. In federated environments, an unverified or changed email can still be accepted by an application that uses it as the user key, which creates impersonation risk across tenants and identity providers.

Q: What do teams get wrong about account merging in multi-IdP applications?

A: Teams often assume that a matching email means the same person, when it only means the same address value. If the application does not verify ownership before linking accounts, an attacker can collide with the victim identity and inherit the victim’s access inside the app.

Q: Who is accountable when a SaaS app accepts the wrong federated identity?

A: The vendor owns the application design, but the customer remains accountable for procurement, configuration review, and ongoing assurance. If a SaaS app cannot prove it uses immutable identity claims correctly, the customer should treat it as a governance issue and not rely on tenant-side detection alone.

Technical breakdown

Why mutable email claims break OIDC identity binding

OpenID Connect provides stable identity primitives, but nOAuth abuse appears when developers ignore them and bind accounts to attributes such as email. Email is useful for contact and lookup, but it is not an immutable subject identifier. In Entra ID, an unverified or changed email can still be emitted as a claim, which means the application may accept the wrong user if it uses that value for account linking. The correct identity anchor is the issuer and subject pair, because those values are stable within the federation relationship.

Practical implication: applications should stop using email as the account key and bind identities to issuer plus subject.

How cross-tenant account takeover happens in vulnerable SaaS apps

The abuse path is simple. An attacker controls an Entra tenant, sets or uses an unverified email address that matches a victim user, and signs in to a vulnerable application that accepts that email as proof of identity. If the app also supports account merging or multiple identity providers, the attacker can collide with the victim account and inherit the target’s in-app access. This is not a token theft problem in the usual sense. It is a federation trust failure caused by the application trusting the wrong claim.

Practical implication: review every SaaS app that links accounts by email and verify whether it validates ownership before merging.

Why customers cannot reliably detect or contain nOAuth abuse

Semperis’ research shows the customer side of the problem is weak. Once the application accepts the bad identity binding, the attacker’s activity can look like ordinary sign-in behaviour because the abuse is happening inside the app’s own trust logic. Customers generally cannot patch the application themselves, and logging may not clearly reveal that the wrong account was accepted. That leaves a governance blind spot where the only effective fix sits with the vendor and the application’s authentication design.

Practical implication: treat vendor verification and post-fix testing as mandatory controls for any SaaS app that consumes Entra identity claims.

Threat narrative

Attacker objective: The attacker aims to impersonate a legitimate user inside a vulnerable SaaS application and access whatever that user can see or do.

1. Entry begins when an attacker uses access to an Entra tenant and a target email address to reach a vulnerable SaaS application.
2. Credential abuse occurs when the application treats the mutable email claim as a valid identity binding and accepts the attacker as the victim user.
3. Impact follows as the attacker inherits the victim’s application permissions, enabling data access, persistence, and possible lateral movement inside the SaaS environment.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mutable identity claims create an account-binding failure, not just an authentication bug. nOAuth abuse works because some SaaS applications still treat email as if it were a durable identity anchor. That assumption was designed for user convenience and contactability, not for security-grade account binding. The implication is that federation governance has to separate stable identity from mutable attributes before account linking logic is trusted.

False identifier logic is a governance problem shared by SaaS, IAM, and application teams. The failure sits at the seam between Entra, the app registration, and the developer’s identity model. When teams merge accounts on the basis of email alone, they are turning a non-authoritative field into an access decision. That is a lifecycle and assurance issue, not merely a coding oversight, and it belongs in access governance reviews.

Vendor-managed fixes do not remove customer accountability for application trust decisions. Semperis’ research shows customers may have no direct remediation path if the SaaS vendor has not reworked its identity binding. That means SaaS procurement, security review, and post-deployment validation must all check for stable identifier use and account-merge safeguards. The practitioner conclusion is simple: if the app cannot prove who the user is, the tenant should not assume it can.

Using issuer plus subject is the right named concept for stable federated identity binding. In OIDC, issuer plus subject is the stable pair that survives the tenant and attribute problems nOAuth exploits. That is the only durable way to prevent cross-tenant impersonation when the application needs to know who a user is. The practitioner conclusion is to treat email as a contact attribute, not an identity key.

nOAuth is a cross-tenant trust collapse, not a one-off application defect. The same pattern can recur anywhere developers reuse convenience attributes for identity correlation. Once that pattern exists, customer controls such as log review or MFA do not address the root issue because the wrong user has already been accepted as the right one. The practitioner conclusion is to inventory federation apps for account-linking anti-patterns and eliminate them at design review.

From our research:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
• A separate finding shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly the visibility gap that makes cross-tenant trust abuse hard to spot, according to The State of Non-Human Identity Security.
• For a broader control lens, teams can compare these trust failures with the governance patterns in Ultimate Guide to NHIs, especially where identity binding and lifecycle assurance intersect.

What this signals

False identifier risk is now a federation governance issue, not a niche developer bug. Teams that run Entra-connected SaaS need to inventory which applications still use email as an account key, then push that question into vendor review and recertification. The control objective is simple: mutable attributes must never drive durable access decisions.

With 85% of organisations lacking full visibility into OAuth-connected vendors, cross-tenant abuse can hide inside ordinary sign-ins. That means detection logic alone will not close the gap. Practitioners need to combine app registration review, identity binding checks, and vendor assurance so that trust decisions are provable before go-live, not after incident response.

Issuer-plus-subject governance should become the default concept for federated identity assurance. When applications rely on the wrong claim, tenant-side controls can look healthy while the app is still accepting the wrong user. The practical signal is whether your SaaS portfolio can demonstrate stable identifier use, not whether it merely supports Entra sign-in.

For practitioners

• Replace email-based account keys Require application teams to bind users with immutable issuer and subject claims, and block account creation paths that key on mutable email attributes.
• Test SaaS account-merge logic Validate whether each Entra-connected application performs ownership proof before merging identities from different sources or tenants.
• Review app registrations for unverified claims Check whether any app registration still accepts unverified email claims and document whether the application consumes them for identity decisions.
• Build vendor verification into procurement Ask vendors to show how they prevent cross-tenant impersonation and require evidence of post-fix testing before approval.

Key takeaways

• nOAuth abuse shows that identity binding fails when applications mistake mutable attributes for proof of identity.
• Semperis found 9 vulnerable applications out of 104 tested, which shows the attack pattern is real and not hard to execute.
• The control that matters most is stable federated identity binding, with issuer plus subject replacing email as the account key.

Key terms

• nOAuth Abuse: A cross-tenant account takeover pattern that exploits SaaS applications which trust mutable identity claims such as email. The attacker uses a federated login path and an application design flaw to become the wrong user, often without needing to break the underlying identity provider.
• Immutable Identifier: A stable identity value that does not change when email addresses, tenant settings, or profile attributes change. In federated identity, immutable identifiers are essential because they let the application keep the correct user binding even when contact data or claims are modified.
• Account Merging Logic: Application logic that combines identities from multiple sign-in sources into one user record. It is useful for user experience, but it becomes a security risk if the merge decision relies on attributes that can be guessed, changed, or reused across tenants.
• Issuer and Subject Pair: The OIDC identity pair that uniquely identifies a user in a specific application relationship. Issuer identifies the token source, while subject identifies the user within that relationship. Together they provide the stable binding needed to avoid cross-tenant impersonation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Semperis: nOAuth abuse research and disclosure findings. Read the original.