TL;DR: Token theft now lets attackers bypass passwords and MFA by abusing OAuth, session, and API tokens that remain valid after authentication, according to Obsidian Security. The security model fails when bearer credentials outlive the controls meant to protect them, making revocation, behavioral monitoring, and integration mapping operational requirements, not nice-to-haves.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “What is Token Theft? OAuth, Session & API Token Attacks Explained”.
Key questions
Q: What breaks when stolen SaaS tokens are still valid after a password reset?
A: Password resets do not reliably end a token-theft incident when the attacker holds refresh tokens, session cookies, or API keys that remain trusted by downstream services.
Q: Why do bearer tokens create more risk than MFA-protected logins?
A: Bearer tokens shift trust from the login event to the token itself.
Q: What do security teams get wrong about OAuth and connected apps?
A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust.
Practitioner guidance
- Audit all live OAuth grants Identify which integrations still hold access to production SaaS data, then remove stale or unused authorisations before they become unnoticed trust paths.
- Revoke refresh tokens during incident response Treat password resets as incomplete containment unless the associated refresh tokens, session tokens, and API keys are explicitly invalidated.
- Map integration chains and downstream reach Document which applications each token can reach so you can estimate blast radius when a vendor, connector, or automation is compromised.
Bottom line: Token theft turns valid SaaS credentials into a bypass path around MFA, which means the decisive control point moves to token issuance and revocation.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Bearer credentials are the real perimeter in SaaS. Password policy and MFA still matter, but they no longer define the decisive control boundary once the platform issues tokens that can be replayed independently of the original user challenge. The security problem is now trust after authentication, not just authentication itself. Practitioners need to treat token governance as a first-class access discipline, especially where integrations and automation are involved.
A few things that frame the scale:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
A question worth separating out:
Q: How should security teams respond when a trusted SaaS integration is compromised?
A: Start by revoking the compromised token, then inventory every related credential, service principal, API key, and downstream system that the app could reach. After that, review scopes, reissue credentials from trusted environments, and monitor for unusual API activity. The goal is to close the trust chain, not just the first entry point.
👉 Read our full editorial: Token theft is bypassing MFA and exposing SaaS trust chains