Topic starter
24/06/2026 11:26 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “nOAuth Abuse Update: Potential Pivot into Microsoft 365”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: nOAuth remains a live governance issue because SaaS apps can convert delegated Microsoft 365 access into a pivot path back into the tenant.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 13 hours ago by NHI Mgmt Group
25/06/2026 8:19 am
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.
A question worth separating out:
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.
👉 Read our full editorial: nOAuth abuse still exposes Microsoft 365 through SaaS apps
This post was modified 13 hours ago by NHI Mgmt Group