Topic starter
08/02/2026 8:26 pm
TL;DR: OAuth tokens bypass SSO and MFA once granted, and RFC 9700 codifies years of breach-driven lessons, from open redirects and consent phishing to persistent refresh tokens and third-party compromise, according to Obsidian Security. The security gap is no longer protocol theory but governance failure: teams must treat OAuth as a standing NHI control plane, not an authentication afterthought.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “OAuth Vulnerabilities Every Security Team Should Know”.
By the numbers:
- The Salesloft-Drift breach affected 700+ organisations and showed how persistent OAuth tokens can extend compromise across many SaaS tenants.
Key questions
Q: What breaks when OAuth tokens are not handled correctly in client applications?
A: Client applications can fail in several ways when token handling is weak.
Q: When does OAuth create more risk than it reduces in SaaS environments?
A: OAuth becomes high risk when scopes are broad, tokens are long-lived, and the organization cannot see how the credential is reused across connected apps.
Q: How do teams know whether OAuth token governance is actually working?
A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner.
Practitioner guidance
- Govern OAuth consent as a privileged workflow Require administrative review for high-risk scopes, pre-authorised apps, and new third-party integrations so delegated access is not treated as routine end-user behaviour.
- Constrain token lifetime and reuse Set explicit expiry limits for refresh tokens, enable rotation where supported, and revoke token families when reuse or replay is detected.
- Audit redirect and grant handling Check authorization servers for exact redirect URI matching, PKCE enforcement, and removal of deprecated flows that still expose tokens.
Bottom line: OAuth breaches persist because delegated tokens keep working after the initial sign-in has been secured.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
08/10/2026 4:33 pm
OAuth is now a standing non-human identity control plane, not an authentication side channel. The bearer token, not the login event, determines effective access once delegation is granted. That means the governance model has to track grants, scopes, rotation, and offboarding with the same seriousness used for other non-human identities. Practitioners should stop treating OAuth as a protocol feature and start treating it as a governed credential system.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: Should organisations treat third-party OAuth apps as part of identity governance?
A: Yes. Third-party OAuth apps can hold valid credentials into SaaS systems, so they are effectively non-human identities with delegated access. That means ownership, approval, scope review, offboarding, and behavioural monitoring should apply to them just as they do to other privileged access paths.
👉 Read our full editorial: OAuth vulnerabilities in SaaS breaches: what security teams miss