nOAuth abuse still exposes Microsoft 365 through SaaS apps

At a glance

What this is: Semperis' follow-up research shows nOAuth abuse still exists in SaaS integrations and can let attackers pivot from a vulnerable app back into Microsoft 365.

Why it matters: This matters because identity teams must govern third-party SaaS authorization paths, refresh-token persistence, and Microsoft 365 exposure as one attack surface across NHI and human access programmes.

By the numbers:

• In testing 38 additional applications since its initial research, Semperis found 2 that were vulnerable to nOAuth abuse.
• 104 applications and found 9 vulnerable.
• That means that as a cumulative percentage, roughly 8% of available apps are vulnerable to nOAuth.

👉 Read Semperis' analysis of nOAuth abuse and Microsoft 365 pivot risk

Context

nOAuth is a SaaS authorization flaw, but the governance problem is broader: applications can keep acting on behalf of users long after the original sign-in moment, especially when refresh tokens and Microsoft Graph permissions are involved. In identity programmes, that means the trust boundary is not the login screen, it is the delegated access path that persists inside the application and reaches Microsoft 365.

Semperis' follow-up research shows the issue is not theoretical or fully contained. The key question for IAM and identity architects is how third-party application consent, token handling, and tenant-level authorization are being controlled when the application itself becomes the enforcement point.

Key questions

Q: How should security teams govern SaaS applications that access Microsoft 365 on behalf of users?

A: Treat each SaaS integration as delegated identity, not just an application. Security teams should inventory Graph permissions, minimise consent scopes, verify token handling, and review whether the app can continue acting through refresh tokens after the user is no longer actively present. The governance control is the delegated path, not only the login event.

Q: Why do refresh tokens make third-party SaaS integrations harder to secure?

A: Refresh tokens let an application obtain new access tokens without requiring the user to sign in again. That persistence is useful for productivity, but it also means the application can continue acting behind the scenes if its authorization model is weak or abused. Security teams need lifecycle controls that cover token persistence, not just sign-in enforcement.

Q: What breaks when authentication and authorization are handled as separate trust decisions?

A: The break is that a successful sign-in no longer proves the resulting action is safe or bounded. If the application can translate that identity into broad Microsoft 365 permissions, the attacker can abuse the authorization path even when authentication looked legitimate. That is why consent, token scope, and downstream API access must be governed together.

Q: Who is accountable when a vulnerable SaaS app can pivot into Microsoft 365?

A: Accountability is shared across the SaaS vendor, the customer, and the identity governance team. The vendor must implement correct OIDC and OAuth handling, while the customer must assess consent scope, review connected applications, and accept that delegated access expands the enterprise perimeter. If no one owns the full path, the risk persists.

Technical breakdown

Authentication and authorization diverge once tokens are issued

OpenID Connect handles authentication with an ID token, while OAuth 2.0 handles authorization with access tokens. When a SaaS application also receives a refresh token, it can keep obtaining new access tokens even when the user is not actively signed in. That separation is normal, but it creates a control gap if the application mishandles claims or token validation. The attacker does not need to break Microsoft 365 directly. Instead, the attacker abuses the application's delegated authority and uses its token lifecycle to act inside Microsoft Graph.

Practical implication: review SaaS integrations as delegated authorization systems, not just sign-in events.

Microsoft Graph permissions define the blast radius

Microsoft Graph is the unified API for Exchange Online, SharePoint, OneDrive, and other Microsoft 365 services. When a third-party application is granted permissions such as Mail.Send, Calendars.ReadWrite, Contacts.ReadWrite, or offline_access, the application's operational scope can extend far beyond the original business function. In the vulnerable case Semperis described, the permissions were broad enough to support email abuse and pivoting back into Microsoft 365. That is why permission scope, not just application identity, determines whether the SaaS integration becomes an enterprise-wide exposure path.

Practical implication: minimise Microsoft Graph consent to the narrowest permission set required for the business use case.

nOAuth abuse turns application consent into a lateral path

The weakness is not a stolen token alone. It is the combination of a vulnerable application, persistent delegated access, and user-context permissions that let an attacker interact through a legitimate SaaS interface. Once the application is abused, the attacker can send mail as the user or reach Microsoft 365 resources through the app's own UI and token handling. That makes detection harder because the action can appear to originate from an approved integration rather than a conventional hostile login.

Practical implication: monitor SaaS-to-Microsoft 365 actions as privileged delegated activity, not ordinary user behaviour.

Threat narrative

Attacker objective: The attacker aims to gain persistent delegated access that can be used to impersonate a legitimate user and extend control into Microsoft 365.

1. Entry occurs through a vulnerable SaaS application that accepts the nOAuth abuse pattern and exposes Microsoft 365 delegated access.
2. Credential abuse follows when the attacker leverages the application's access and refresh token handling rather than stealing the token directly.
3. Impact is achieved when the attacker uses the app's delegated permissions to send mail as the user and pivot back into Microsoft 365.

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

Delegated SaaS access is now part of the Microsoft 365 identity perimeter. nOAuth shows that authorization cannot be treated as an application-local concern when third-party SaaS apps can act through Microsoft Graph on behalf of users. The application becomes an identity enforcement layer, which means tenant exposure is created by delegated permissions as much as by direct account compromise. Practitioners should treat SaaS consent and Microsoft 365 access as one control domain.

Authentication and authorization are being separated from the control assumption they were designed for. The assumption was that a user signs in, the application authorizes a bounded action, and the resulting access remains understandable to the tenant. That assumption fails when a refresh token allows continued access and the application itself mediates the activity path. The implication is that governance cannot rely on sign-in success as evidence of safe authorization.

nOAuth is a third-party access governance failure, not a niche application bug. Semperis found 2 vulnerable applications in 38 additional tests, and its cumulative sample still landed at roughly 8% vulnerable. That is enough to show persistent category risk, not an edge case. The practical conclusion is that identity governance teams need a repeatable process for evaluating SaaS consent, token persistence, and Graph permission scope before onboarding.

Microsoft 365 exposure now depends on how the SaaS layer manages delegated identity lifecycle. If the application can retain access, renew tokens, and continue acting after the user is no longer actively present, then offboarding and review controls must include the application path, not only the user account. That widens the governance surface from access approval to lifecycle accountability across the SaaS relationship.

Third-party SaaS integrations create an identity blind spot when customers cannot defend themselves against abuse. The most difficult part of nOAuth is that the vulnerable application controls the behaviour, while the tenant often has little direct enforcement power. That is a classic delegated-trust problem, and it argues for stronger pre-onboarding assurance, permission minimisation, and continuous review of connected applications.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader breach pattern view, see 52 NHI Breaches Analysis and compare how persistent credentials extend attack windows.

What this signals

Delegated identity is becoming a hidden control plane for Microsoft 365. The immediate programme impact is that SaaS onboarding, consent review, and token lifecycle management need to sit inside the same governance workflow as privileged access. If your team cannot explain which apps can act through Microsoft Graph, then you do not have a complete identity map for the tenant.

Ephemeral sign-in does not equal ephemeral access. When refresh tokens and long-lived delegated permissions exist, the access window can outlast the human interaction that initiated it. Teams should expect more pressure to evidence token persistence controls, especially where the application can send mail or manage calendars on the user's behalf.

91.6% of secrets remain valid five days after notification, showing how slowly remediation often moves in practice. That same persistence mindset applies to third-party delegated access, which is why connected SaaS applications should be revalidated on a fixed cadence and not only at onboarding. For the underlying model, practitioners should anchor their review in the Ultimate Guide to NHIs and Microsoft's NIST SP 800-63 Digital Identity Guidelines where federation and authenticator assurance intersect.

For practitioners

• Inventory every SaaS app with Microsoft Graph consent Build a complete list of applications granted Exchange Online, SharePoint, OneDrive, or Mail.Send style permissions, then classify each one by business criticality and delegated reach. Do not stop at the app catalogue; include the effective tenant access that the app can exercise through tokens.
• Minimise delegated permission scope before onboarding Reject broad permission bundles when the business need can be met with narrower scopes, and specifically scrutinise offline_access because it extends token lifetime beyond the active session. Treat the requested scope as an identity governance decision, not a procurement checkbox.
• Validate token and claim handling in SaaS integrations Ask vendors how they process authentication claims, refresh tokens, and email assertions, and require evidence that the application follows Microsoft guidance for OIDC and OAuth separation. Where the vendor cannot explain the flow clearly, assume the integration needs additional control review before approval.
• Monitor delegated activity as privileged behaviour Add detections for unusual Microsoft 365 actions coming from approved SaaS applications, especially mail sending and calendar manipulation from apps that normally operate quietly in the background. Identity teams should review these events as delegated privilege use, not standard end-user activity.

Key takeaways

• nOAuth is a delegated access problem that can let a SaaS app act back into Microsoft 365 with legitimate-looking permissions.
• The research sample is still large enough to show persistent risk, with 2 vulnerable apps found in 38 new tests and roughly 8% vulnerability across the cumulative sample.
• Identity teams should govern Microsoft Graph consent, refresh-token persistence, and SaaS offboarding as one lifecycle, not three separate tasks.

Key terms

• Delegated Authorization: Delegated authorization is when an application acts on a user's behalf after the user grants it permission. In Microsoft 365 integrations, the app may receive scoped access tokens and continue operating even when the user is not actively signed in, which makes token lifecycle and consent review governance-critical.
• Refresh Token: A refresh token is a credential that allows an application to obtain new access tokens without forcing the user to sign in again. It extends operational continuity, but it also extends the attack window if the application is compromised, over-permissioned, or built with weak claim validation.
• Microsoft Graph Permission Scope: Microsoft Graph permission scope defines what a connected application can do across Exchange Online, SharePoint, OneDrive, and related Microsoft 365 services. The scope is a governance boundary, because broad permissions can turn a single SaaS integration into a tenant-wide access path.

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 lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Semperis: nOAuth abuse still exposes Microsoft 365 through SaaS apps. Read the original.