Topic starter
08/02/2026 8:29 pm
TL;DR: OAuth tokens are bearer credentials that can outlive passwords, MFA, and user memory, enabling persistent SaaS access and lateral movement when integrations are over-scoped or compromised, according to Obsidian Security. The security problem is not token issuance alone, but the weak governance around discovery, scope review, and revocation.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “What are OAuth Tokens? How It Works, and Its Vulnerabilities”.
By the numbers:
- According to Obsidian Security, the average enterprise has over 1,000 active OAuth integrations.
- According to Obsidian Security, organizations conducting OAuth scope audits commonly find that 60-80% of integrations have permissions exceeding operational requirements.
- According to Obsidian Security, the Salesloft-Drift breach showed tokens from an integration provider granting access to over 700 organizations.
Key questions
Q: What breaks when OAuth tokens are treated as permanent access?
A: Permanent OAuth access turns a delegated token into standing privilege, which means a compromise can be reused until someone revokes it.
Q: Why do over-scoped OAuth permissions create more risk than many SSO and MFA controls can stop?
A: OAuth tokens can grant direct access to data and application functions after a user approves an app, so they often bypass the protections people associate with SSO and MFA.
Q: How do security teams know if OAuth abuse is slipping past detection?
A: The warning signs are gaps between user activity and identity telemetry.
Practitioner guidance
- Inventory every OAuth integration Build a complete register of applications, scopes, refresh token lifetimes, owners, and downstream systems for each SaaS tenant.
- Reduce scopes to the minimum required Review granted permissions against actual task needs and remove write, offline access, or admin scopes that are not operationally necessary.
- Set expiration for refresh tokens Apply maximum lifetimes and periodic re-authorization for sensitive integrations so delegated access does not persist indefinitely.
Bottom line: OAuth token risk is really a governance problem around delegated access, not a failure of the OAuth standard itself.
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:34 pm
OAuth tokens expose an identity governance gap, not just an authentication gap. The article shows that the security problem begins after authentication has already succeeded, when delegated access is granted to applications that sit outside the normal user-login boundary. That means IAM programmes focused only on human sessions miss the operational reality of SaaS trust chains. Practitioners need to treat token governance as part of the identity control plane, not a side issue.
A few things that frame the scale:
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
A question worth separating out:
Q: Should organisations treat SaaS integrations like non-human identities?
A: Yes. SaaS integrations use OAuth tokens, API keys, and service accounts that function as non-human identities, so they need discovery, ownership, expiry, and offboarding controls. If teams leave them outside IAM governance, they become dormant trust relationships that can persist for months or years.
👉 Read our full editorial: OAuth tokens and SaaS supply chain risk: why IAM controls fail