Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

nOAuth abuse in SaaS apps: are Microsoft 365 controls enough?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 12212
Topic starter  

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:

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

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11787
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: nOAuth abuse still exposes Microsoft 365 through SaaS apps



   
ReplyQuote
Share: