TL;DR: Two vulnerable applications were found in 38 additional nOAuth tests, bringing the cumulative sample to roughly 8% vulnerable and showing that attackers can pivot from a SaaS app back into Microsoft 365 through access and refresh tokens, according to Semperis. That disconnect between authentication and authorization remains a governance failure, not just a product bug.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Semperis's research: nOAuth abuse still affects SaaS applications, with vulnerable apps able to pivot from third-party access back into Microsoft 365 through OAuth tokens and refresh tokens.
Why it matters: For IAM teams, this shows that delegated SaaS access can become an enterprise-wide identity risk when application consent, token handling, and Microsoft 365 authorisation are not governed as one lifecycle.
Context
nOAuth is an abuse pattern in which a vulnerable SaaS application can be used to pivot from a third-party app back into Microsoft 365 through OAuth access and refresh tokens. In this case, the primary identity problem is not sign-in but delegated authorisation that outlives the user interaction that created it.
Semperis tested 38 additional applications and found 2 vulnerable, after earlier testing had found 9 vulnerable in 104 applications. The article argues that customers of vulnerable applications have little practical defence once the app is in use, because the abuse happens through the SaaS app’s own token handling and Microsoft Graph permissions.
The Microsoft 365 integration layer is typical of many enterprise SaaS deployments, not an edge case. That makes the finding relevant to programme owners who treat third-party app consent, token issuance, and downstream mailbox access as separate controls.
Key questions
Q: What breaks when a SaaS app can reuse Microsoft 365 tokens after sign-in?
A: The main failure is that the application becomes a persistent access broker rather than a one-time authenticator. If refresh tokens can be renewed after the user is gone, the app can continue acting inside Microsoft 365 even when the human session has ended. That breaks the assumption that user authentication and application authorization naturally expire together.
Q: Why do delegated SaaS permissions create Microsoft 365 risk even without direct password theft?
A: Because the attacker may not need the password at all. If the app already holds the right tokens and permissions, abuse can happen through the SaaS workflow itself. That makes consent scope, token reuse, and application claims validation the real control points for tenant protection.
Q: What signs suggest a SaaS integration is too powerful for its business need?
A: Look for apps that can send mail, read mail, or modify calendars when the business use case only needs limited scheduling or data sync. Also treat offline access, broad Microsoft Graph scopes, and long-lived refresh tokens as indicators that the app can outlive the intended user action and become a tenant-level exposure path.
Q: How should teams evaluate SaaS app onboarding after an nOAuth finding?
A: They should verify the app’s OAuth and OIDC design, confirm how claims are validated, and review whether the requested Microsoft 365 permissions are proportionate to the use case. If the app can act as the user with broad Graph access, onboarding should be paused until the trust model is clear.
Technical breakdown
How nOAuth turns OAuth consent into Microsoft 365 access
nOAuth exploits the difference between authentication and authorization in OpenID Connect and OAuth 2.0. Authentication establishes the user, but authorization determines what the SaaS application may do with Microsoft 365 data. If the application accepts a weak email-claim flow, an attacker can abuse the app’s token exchange path and operate through legitimate Microsoft Graph permissions without needing direct control of the user’s Microsoft 365 credentials. The risk increases when the app holds refresh tokens, because those tokens let the app continue obtaining access tokens after the user is no longer actively signed in.
Practical implication: review how SaaS apps obtain and reuse Microsoft Graph tokens, not just whether the user has consented.
Why refresh tokens extend the abuse window
A refresh token lets a SaaS application request new access tokens over time, which means the security boundary is the application’s token logic, not the user’s current login state. That matters because the attacker does not need to steal the raw access token if they can manipulate the application workflow that sits around it. In practice, this creates an identity control problem at the app layer: permissions may be legitimate on paper, but the application’s handling of claims, consent, and token refresh can still enable impersonation and mail actions in Microsoft 365.
Practical implication: govern refresh-token usage as a privileged capability, especially where the app can send mail or access calendars.
How Microsoft Graph permissions create pivot paths
Microsoft Graph is the shared API surface for Exchange Online, SharePoint, OneDrive, and related Microsoft 365 services. When a SaaS app receives broad permissions such as Mail.Send or Calendars.ReadWrite, the app can act inside the tenant in ways that resemble legitimate user activity. That is why nOAuth is not limited to data exposure inside the SaaS app itself. Once the app can operate through Microsoft 365 permissions, the attacker can use the SaaS interface as a proxy for actions that would otherwise require direct tenant access.
Practical implication: classify Microsoft Graph permissions by downstream tenant impact, not by the SaaS app’s business purpose.
Threat narrative
Attacker objective: The attacker wants to use a SaaS application as a bridge into Microsoft 365 and operate as a legitimate user to enable mailbox abuse, data access, or lateral movement.
- Entry occurs through a vulnerable SaaS application that accepts the nOAuth pattern and issues Microsoft 365 tokens through its normal consent flow.
- Credential access is achieved through access and refresh tokens managed by the application, which lets the attacker keep obtaining valid Microsoft Graph access without direct user reauthentication.
- Escalation and impact follow when the app has broader Microsoft 365 permissions, allowing the attacker to send mail or act as the compromised user inside the tenant.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Mimecast certificate compromise 2021: SolarWinds attackers stole a Mimecast certificate that authenticated to Microsoft 365 Exchange and used it against a few customer tenants.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authentication and authorization separation is the control gap nOAuth exploits. The article shows that treating sign-in and delegated access as independent functions creates a blind spot in Microsoft 365-integrated SaaS governance. The user may authenticate cleanly while the application retains broad authorisation through tokens that outlive the interaction. Practitioners should treat the app-to-tenant trust boundary as the real control surface, not the login ceremony.
Refresh tokens turn a one-time consent event into persistent delegated access. That persistence matters because the application can keep requesting new access tokens even when the user is not actively present. In identity governance terms, the risky asset is not the user session alone but the app’s ongoing ability to act through Microsoft Graph. This is where SaaS lifecycle governance and Microsoft 365 governance converge.
Microsoft 365 abuse via SaaS apps is now a governance problem, not a niche protocol flaw. Semperis’ findings show that the issue persists across repeated testing, which means organisations cannot rely on one-off remediation assumptions. The named concept here is delegated token drift: application permissions and token reuse gradually create a wider effective trust zone than the original consent intended. Security teams need to govern that drift as a standing programme concern.
Customers of vulnerable SaaS apps have limited downstream defence once the integration is live. The article makes clear that once the app is integrated, the customer often cannot detect or block the abuse from the Microsoft 365 side alone. That shifts emphasis toward onboarding decisions, vendor due diligence, and permission review before integration becomes operational. The implication is that consent governance must be treated as a tenant protection control, not a procurement formality.
This pattern validates a broader identity lesson: app-layer trust can override tenant-layer intent. A tenant may believe it has constrained access through Microsoft Entra ID, while the application still retains enough delegated authority to impersonate the user inside Microsoft 365. That mismatch is why NHI governance and SaaS app governance increasingly overlap. Practitioners should assume the application boundary can become the weakest link in enterprise identity assurance.
What this signals
Delegated token drift: once a SaaS app can renew Microsoft 365 access on its own schedule, the practical trust boundary extends beyond the user session and into the application’s token lifecycle. That is why consent reviews and app offboarding now belong in the same governance conversation as tenant access controls.
Security teams should treat Microsoft Graph permissions as downstream tenant privileges, not just integration settings. A calendar app that can send mail or renew access silently is not a benign connector, it is a standing trust path that needs lifecycle governance and periodic re-approval.
For practitioners
- Audit SaaS apps for Microsoft Graph privilege scope Inventory third-party applications that request Exchange Online, SharePoint, or OneDrive permissions and rank them by their ability to send mail, read mail, or manage calendars.
- Review refresh-token handling in integrated apps Identify applications that can renew access without active user presence and verify whether the token lifecycle is bounded by revocation, consent changes, or tenant offboarding.
- Block weak email-claim patterns before onboarding Require vendors to show how their OIDC implementation validates identity claims and prevents the app from accepting unverified email assertions as a trust signal.
- Tie app consent to tenant-level risk review Treat mailbox, calendar, and contacts permissions as high-impact authorisations that need explicit approval and periodic recertification, not silent admin enablement.
Key takeaways
- nOAuth remains a live governance issue because SaaS apps can convert delegated Microsoft 365 access into a pivot path back into the tenant.
- Semperis found 2 vulnerable applications in 38 additional tests, reinforcing that the pattern persists across a small but meaningful sample.
- The practical control point is not only user authentication but also token handling, consent scope, and the application’s ability to renew access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on a vulnerable OIDC and OAuth claim flow that enables SaaS abuse. |
| NHI-05 — Overprivileged NHI | The risky apps hold broader Microsoft 365 permissions than their business use requires. | |
| NHI-07 — Long-Lived Secrets | Refresh tokens extend the abuse window beyond the active user session. | |
| Recommendation — Validate claim handling and consent flows to prevent weak authentication from enabling delegated abuse. Reduce app scopes to the minimum Microsoft Graph permissions needed for the use case. Bound refresh-token lifetime and revoke persistent app access when trust changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token handling and renewal are central to the abuse path described in the article. |
| Recommendation — Manage application authenticators and token lifecycles as revocable credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is excessive delegated authorization into Microsoft 365 services. |
| Recommendation — Review and constrain SaaS entitlements that can reach Microsoft 365 data and actions. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The abuse path uses token access to move from a SaaS app into Microsoft 365. |
| Recommendation — Map token-abuse paths to credential access and lateral movement to improve detection. | ||
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.
- Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
- Microsoft Graph: Microsoft Graph is the access and data layer that connects Microsoft 365 services, including mail, files, chats, and sites. In Copilot workflows, it becomes the retrieval surface that determines what information the assistant can assemble into a response.
- Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org