Credential theft vs token theft: why SaaS controls miss both

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Obsidian Security's blog post: Credential theft and token theft in SaaS differ, and tokens can bypass MFA and leave no login evidence.

Why it matters: IAM and security teams need unified visibility across authentication, sessions, and integrations because controls built only around login events miss token-based account takeover and SaaS-to-SaaS lateral movement.

By the numbers:

• Credential theft remains the dominant attack vector at 88% of breaches.
• PhaaS platforms now capture both credentials and tokens simultaneously in 63% of incidents.
• Threat actors exploit stolen credentials within an average of 14 minutes.
• Security teams blocked 4.2 billion credential stuffing attempts in 2025.

Context

Credential theft and token theft are different control problems. Credentials still require authentication and often trigger logs, MFA, and anomaly checks, while bearer tokens and OAuth refresh tokens represent already-authenticated access that can be replayed without a new login event.

That distinction matters because SaaS environments now depend on federated sign-in, long-lived sessions, OAuth integrations, and downstream app connections. When detection and response are built around login telemetry only, token abuse can persist invisibly until data movement or lateral access exposes it.

The article's core problem is not just stolen secrets, but the mismatch between identity controls designed for authentication and attackers exploiting post-authentication access. For SaaS identity governance, the control boundary now extends beyond the login prompt into session state and delegated access.

Key questions

Q: What breaks when SaaS controls focus only on login events?

A: Controls that watch only logins miss the post-authentication layer where bearer tokens operate. Attackers who steal a token can access SaaS applications without triggering a new MFA challenge, failed login, or suspicious sign-in event. That leaves the most dangerous activity outside the detection logic many teams still rely on.

Q: Why do forged or stolen SaaS tokens create such high risk for downstream email and data access?

A: Forged or stolen tokens bypass normal interactive login controls and can inherit the privileges already attached to the session or service. In SaaS environments, that means an attacker may move directly to email, files, or APIs without triggering the same friction as password attacks. If the token is valid and trusted, the platform may treat the attacker as an authorised user.

Q: How should teams respond when a credential or token is discovered outside its expected domain?

A: Contain the affected identity first by revoking or narrowing the trust path before the credential can be reused elsewhere. Then trace which systems accepted it, which scopes it held, and which integrations inherited access from it. The priority is to stop replay and reduce the blast radius before further lateral use occurs.

Q: When should organisations prioritise OAuth integration review over password policy changes?

A: When the environment relies on SaaS integrations, OAuth consent, and long-lived refresh tokens, integration review should move up the queue. Stronger passwords help against credential theft, but they do not address bearer-token replay or overly permissive app consent. In those environments, the integration layer often defines the real blast radius.

Technical breakdown

Why bearer tokens bypass SaaS authentication controls

Bearer tokens work on possession, not re-authentication. In SaaS and OAuth ecosystems, a valid access token or refresh token can be exchanged for new access without the user re-entering a password or completing MFA. That means the control plane shifts from identity proofing at login to possession of an active session artifact. If a token is stolen, the attacker inherits the authenticated context, including application permissions and connected integrations. Traditional monitoring that keys on failed logins, impossible travel, or MFA prompts will miss this path because no new authentication event occurs.

Practical implication: monitor token issuance, reuse, and session replay as first-class identity events, not just login telemetry.

How credential theft and token theft combine in PhaaS attacks

Phishing-as-a-Service platforms increasingly run an Adversary-in-the-Middle flow that captures both the password and the resulting token in one interaction. The victim authenticates to the real service through the attacker relay, so the service issues a legitimate session while the attacker retains the credential set and the token. That dual capture defeats simple remediation sequencing because password resets do not invalidate the token and session revocation does not remove the stolen password. In practice, the attack chain is designed to preserve at least one surviving access path until both artefacts are revoked.

Practical implication: treat password resets and session invalidation as a paired response, not separate remediation steps.

Why OAuth integrations expand the blast radius of token theft

OAuth tokens do more than open the primary SaaS account. They often inherit access to connected applications, API actions, and third-party workflows that were granted at consent time and may never be reviewed again. That creates a delegated access chain in which one stolen token can extend into email, files, calendars, or downstream business apps without another authentication challenge. The technical risk is not only account takeover, but untracked privilege propagation across integrations that were assumed to be low-friction and low-risk. In SaaS, the token is often the key to an entire application mesh.

Practical implication: inventory OAuth grants and connected apps as part of your access model, not as a separate app-admin task.

Threat narrative

Attacker objective: The attacker wants durable SaaS account access that survives password resets and provides reach into connected applications and administrative functions.

1. Entry begins with phishing, malware, or credential stuffing that captures usernames, passwords, or both credentials and session material in a single relay.
2. Credential access or token capture then gives the attacker authenticated or re-authenticated access without needing to defeat MFA again.
3. Escalation occurs when the stolen token or refresh token is used to access connected SaaS apps, API actions, or admin functions under the victim's session context.
4. Impact follows as the attacker moves laterally across integrated services, exfiltrates data, or preserves persistence through long-lived refresh tokens.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication-centric controls are no longer sufficient for SaaS identity governance. Login monitoring, MFA challenges, and device-based anomaly detection all assume the attacker must pass through the authentication moment. Token theft breaks that model because the attack can begin after authentication has already succeeded. The practitioner conclusion is that SaaS governance has to treat sessions and delegated access as part of the identity perimeter, not as an application detail.

Session state has become a governance surface, not just a runtime convenience. OAuth refresh tokens and bearer tokens create access that can outlive the login event that created them. That changes the control objective from proving who authenticated to governing how long authenticated context remains valid and where it can be replayed. The practitioner conclusion is that access review without session review is incomplete.

Identity blast radius is now determined by integration depth. A stolen token rarely stops at the first application because SaaS environments are connected through consented app chains, API permissions, and shared business workflows. That means one session compromise can translate into many service compromises without additional prompts or logs at the primary identity layer. The practitioner conclusion is that integration inventory is now an identity control, not a shadow IT exercise.

Bearer-token trust is the specific failure mode this article exposes. Token-based SaaS access was designed for convenience and portability, but it assumes possession of the token is enough to represent legitimate continuity of the session. That assumption fails when an attacker can steal the token independently of the user and replay it elsewhere. The practitioner conclusion is that possession-based trust needs tighter binding, shorter lifetimes, and continuous validation.

The market problem is unified visibility, not another isolated detector. The article shows that credential-focused tools and token-focused tools both miss part of the attack chain when they operate in silos. A practitioner-grade programme has to correlate authentication events, session artefacts, token behaviour, and integration grants in one governance picture. The practitioner conclusion is that fragmented identity telemetry now underestimates SaaS compromise risk.

From our research library:

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

What this signals

Bearer-token trust: SaaS programmes still assume that holding a valid token proves legitimate continuity of access. That assumption fails once tokens are stolen independently of the user, so governance has to move from authentication-only controls to session-bound visibility and token lifecycle oversight.

The practical shift is to treat OAuth consent, refresh-token lifetime, and session revocation as part of the identity programme, not as peripheral app-admin tasks. Teams that do not unify those signals will continue to underestimate account compromise and SaaS-to-SaaS movement.

For practitioners

• Map token-bearing access paths Inventory access tokens, refresh tokens, OAuth grants, API keys, and connected SaaS apps for every critical tenant. Prioritise the accounts whose tokens can reach email, files, admin consoles, or downstream integrations.
• Pair credential and session revocation Update response playbooks so password resets always include active-session invalidation, token revocation, and review of newly issued tokens. One action without the other leaves a surviving access path.
• Monitor token behaviour, not only logins Add detections for anomalous token use, unusual ASN or User-Agent patterns, replay from multiple locations, and access from devices that do not match the original session context.
• Shorten token lifetime and rotate refresh tokens Enforce shorter access-token TTLs, rotate refresh tokens on use, and bind sessions to device or posture signals where the platform allows it.
• Audit third-party app consent regularly Review OAuth app permissions on a fixed schedule and revoke stale or overprivileged integrations that would let a stolen token expand into other business systems.

Key takeaways

• Credential theft and token theft are different stages of the same SaaS compromise problem, and each requires different detection logic.
• Bearer tokens can preserve access after MFA, password resets, and login-based monitoring have already failed to see the attacker.
• The most effective response is unified visibility across credentials, sessions, and integrations, because that is where the real blast radius emerges.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• OAuth Refresh Token: An OAuth refresh token is a long-lived credential that lets an application request new access tokens without asking the user to log in again. In practice, it behaves like a reusable access key, so compromise can create persistent access until the token is revoked or expires.
• Adversary-in-the-Middle (AiTM): An attack pattern where the adversary sits between the user and the service to capture or replay authentication data and session state. The victim may still log in successfully, which is why the compromise often appears legitimate until privileged actions begin. AiTM is especially dangerous for admin workflows that trust issued sessions too much.
• Session revocation: The ability to invalidate active sessions so access ends immediately instead of waiting for tokens or browser state to expire. For identity governance, this is the control that determines whether authentication still matters after a compromise is detected.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.