What is a refresh token?
A refresh token is a long-lived OAuth credential issued after authentication that lets applications obtain fresh access tokens without re-authenticating the user. In enterprise settings it’s typically valid 14–90 days (up to 90 by default in Microsoft Entra ID and Okta). That longevity creates a seamless experience – and makes a stolen refresh token extraordinarily dangerous.
Why a stolen refresh token is worse than a stolen session cookie
A session cookie grants access to one application for a finite session. A stolen refresh token is renewable: the attacker presents it to the IdP, gets a fresh access token, and repeats for the token’s entire lifetime – up to 90 days – without ever triggering an authentication event or MFA prompt.
The critical trap: password resets don’t invalidate refresh tokens. A team that responds to a stolen token by only resetting the password leaves the attacker with uninterrupted access for the token’s remaining life.
Refresh tokens are captured by both infostealers and AitM phishing and sold alongside session cookies.
See how often these session artifacts surface in criminal markets in the 2026 Annual Identity Exposure Report →
What complete refresh-token remediation requires
Refresh tokens are captured via infostealer malware (pulled from browser and OS credential stores) and AitM phishing (intercepted at issuance). Closing the exposure takes a three-step sequence:
- Revoke at the IdP. Kill the refresh token itself.
- Terminate the SSO session. Cascade revocation to downstream apps.
- Invalidate app-level cookies. Close any sessions already minted.
- Automate it. SpyCloud Session Identity Protection detects stolen refresh tokens and runs this sequence through Okta, Entra ID, and Active Directory Guardians within minutes of a match.
Refresh token vs. access token vs. session cookie
Three post-login artifacts get conflated, and the differences decide how an attacker uses each:
- Access token – short-lived, often minutes; proves authorization for specific requests. Limited value if stolen alone.
- Session cookie – browser-stored; keeps a user logged into one application until it expires or is killed.
- Refresh token – long-lived, up to 90 days; mints fresh access tokens without re-authentication, and a password reset doesn’t revoke it.
An attacker who steals a refresh token doesn’t need the other two – they can continuously regenerate access for the token’s entire lifetime.
A stolen refresh token can keep an attacker in for 90 days past your password reset.
Check Your Exposure to see what session artifacts tied to your domain are exposed.
Frequently Asked
No. In most IdP configurations they’re independent. A refresh token is issued after authentication and tracks its own expiry separately from the password. A reset doesn’t automatically revoke outstanding refresh tokens unless explicitly configured to – and most defaults don’t. The attacker keeps minting access tokens for the token’s remaining life, up to 90 days, regardless of the password change.
A session cookie is browser-stored and identifies an active session with one application, usually expiring on browser close or timeout. A refresh token is an IdP-level OAuth credential that obtains new access tokens without re-authentication, with much longer validity. Stealing a cookie grants access for its remaining validity; stealing a refresh token lets an attacker renew access continuously for up to 90 days.
It recaptures them from criminal markets where AitM operators and infostealer distributors sell captured session artifacts. The recaptured dataset includes the full session package – cookies, refresh tokens, and account metadata – not just the credential. On a domain match, Session Identity Protection signals the IdP to revoke the token immediately, before the access window can be used for lateral movement or ransomware.