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.
NHIMG editorial — based on content published by Semperis: nOAuth abuse still exposes Microsoft 365 through SaaS apps
By the numbers:
- That means that as a cumulative percentage, roughly 8% of available apps are vulnerable to nOAuth.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Semperis' full post covers the operational detail this analysis intentionally leaves for the source:
- A walk-through of how Microsoft Graph permissions, ID tokens, access tokens, and refresh tokens interact in nOAuth scenarios
- The specific vulnerable permission set observed in the latest testing, including why Mail.Send and offline_access increase risk
- The attack simulation showing how an attacker can send email as the compromised user from the SaaS interface
- Semperis' timeline of MSRC engagement and the response it received on severity classification
👉 Read Semperis' analysis of nOAuth abuse and Microsoft 365 pivot risk →
nOAuth abuse in SaaS apps: are Microsoft 365 controls enough?
Explore further