Stolen OAuth Tokens Outlive Password Resets: Hardening Session Material in SaaS Estates

When an attacker steals a password, you reset it. When an attacker steals a refresh token, a password reset does not necessarily help, and many incident responders discover this at the worst possible moment. Session material has become the preferred credential in SaaS environments because it is portable, long-lived and rarely inventoried.

Why the reader needs this

Modern SaaS access is a chain of tokens: an identity provider issues an access token and a refresh token, the client stores them, and downstream applications accept them without re-checking the user. If a token is exfiltrated from a browser profile, a CI secret, a logging pipeline or a compromised laptop, it can be replayed from anywhere the issuer accepts. The account owner may see nothing unusual, because the session is legitimate from the provider's perspective.

Technical context: which artifacts survive what

Different credential artifacts have different lifetimes and different remediation paths:

• Access tokens are typically short-lived, often under an hour. Revoking them is time-bounded and mostly automatic.
• Refresh tokens are the durable artifact. They can be valid for days or months, and they are what allows an attacker to mint new access tokens after the original expires.
• Session cookies for browser-based single sign-on can persist for weeks if the provider allows long sessions, and they may be bound to nothing more than a cookie value.
• Service account keys and client secrets never expire unless someone rotates them, and they are frequently pasted into CI variables, wikis and chat messages. The critical asymmetry is that password reset invalidates a password, not necessarily a token. Providers differ in whether a password change revokes existing refresh tokens, and in whether an administrator can enumerate and revoke sessions for a user. ## A concrete failure chain This chain is a composition of publicly documented token-theft patterns, presented as a reasoning model rather than a specific incident report.
• An attacker obtains a refresh token, through infostealer malware on an employee laptop, a misconfigured log that captured an authorization header, or a leaked CI secret.
• The attacker exchanges the refresh token for a new access token from the legitimate identity provider.
• No password is used, so no password-based anomaly detection fires.
• The attacker enumerates the SaaS estate using the token: mail, file storage, source control, depending on granted scopes.
• The victim detects the intrusion and resets the password. The refresh token remains valid, so the attacker continues. The window between detection and actual containment is where the damage accumulates, and it is determined by whether the responder knows to revoke tokens rather than just credentials. ## Defensive implications Know your revocation surface. Before an incident, document for each identity provider whether an administrator can list active sessions and revoke refresh tokens, and whether a password change does so automatically. This is a five-minute question with a multi-day answer during an incident. Bind tokens to something. Token binding, sender-constrained tokens such as DPoP, or certificate-bound tokens make a stolen token useless without the corresponding key. Where the provider supports it, this converts token theft from a full account compromise into a failed request. Shorten refresh token lifetime and rotate. Rotation with reuse detection means a stolen token that is used after the legitimate client refreshes it triggers an alert and invalidates the family. Inventory non-human credentials. Service account keys and client secrets should have owners, expiry dates and a rotation schedule. An unrotated key is a permanent credential. Detect replay, not just login. Alert on the same refresh token being used from two geographies, on token exchanges from unexpected user agents, and on first-time access to sensitive scopes. Login-based detection misses this entirely. Reduce scope by default. A token that can read mail and write files is worth more to an attacker than one that can only read a calendar. Request the narrowest scope the integration needs. ## Limits of this analysis Token binding requires client support and is not universally available. Rotation can break poorly written integrations that assume a refresh token is permanent, so it must be tested. Session revocation tooling varies widely between providers, and in some cases the only reliable containment is to disable the account and re-enroll the user. These constraints are the reason token hygiene is an architectural problem rather than a checkbox. ## References
• OAuth 2.0 Security Best Current Practice (RFC 9700): https://www.rfc-editor.org/rfc/rfc9700.html
• OAuth 2.0 Demonstrating Proof of Possession (DPoP), RFC 9449: https://www.rfc-editor.org/rfc/rfc9449.html
• OAuth 2.0 Token Revocation, RFC 7009: https://www.rfc-editor.org/rfc/rfc7009.html
• MITRE ATT&CK, Steal Application Access Token (T1528): https://attack.mitre.org/techniques/T1528/