Skip to content
Start with Identity
Join free
SWI-T008 · Session and tokens

Refresh token abuse

A refresh token exists to let an app get new access tokens without bothering the user again. Stolen, it lets an attacker do the same thing indefinitely, surviving password resets along the way.

WidespreadHard to detect
First observed: 2018ATT&CK T1528 ↗ATT&CK T1550.001 ↗

How it works

OAuth access tokens are deliberately short-lived, often valid for an hour or less, to limit the damage if one leaks. A refresh token is what makes that usable: a longer-lived credential the client presents to the authorization server's token endpoint, with grant_type=refresh_token, to get a fresh access token without asking the user to sign in again. Clients get one by requesting it at authorization time, usually through the offline_access scope or a provider-specific equivalent.

Refresh tokens are what device code phishing, AiTM proxies, malicious OAuth consent grants and infostealers are actually after. A stolen access token expires on its own; a stolen refresh token keeps producing new ones for as long as it stays valid. In Microsoft Entra ID the default refresh token lifetime is 90 days for most clients and 24 hours for single-page apps, and each refresh returns a new refresh token, so a token in regular use effectively never ages out. Microsoft's documentation also states that the platform does not revoke the old refresh token when it is used, so a copy taken from a device keeps working alongside the legitimate one.

There are two common shapes.

  1. User refresh tokens. Taken from a phished session, a device-code grant, a stealer log or a compromised add-in. The attacker runs it through the same token endpoint the legitimate application uses, requesting access tokens for mail, files or directory APIs on their own schedule. Some first-party clients can also exchange a refresh token for tokens to other resources. Microsoft observed Storm-2372 in February 2025 using the Microsoft Authentication Broker client ID so that its device-code refresh token could request a token for the device registration service, register an attacker-controlled device in Entra ID, and obtain a Primary Refresh Token.
  2. Integration refresh tokens. A SaaS integration holds refresh tokens for every customer tenant that connected it. Steal the integration's token store and you hold standing, MFA-free access to all of them at once. That is how the Salesloft Drift and Gainsight incidents reached Salesforce customers in 2025.

Either way, the requests are the same ones the real client makes.

Why it works

Refresh tokens exist specifically to reduce user friction, and reducing friction means reducing the number of checkpoints where a defender or the user could notice something wrong. A stolen refresh token requires no further interaction from the victim: no MFA prompt, no login screen, nothing to see or approve, because the exchange happens entirely between the attacker's client and the token endpoint. The control assumption that fails is that a token is only ever presented by the client instance it was issued to. RFC 6749 binds refresh tokens for confidential clients to the client's credentials, but public clients (mobile apps, desktop apps, browser apps, and many first-party clients) have no secret, so the token alone is enough.

The second assumption that fails is that credential lifecycle events end access. A password reset addresses the credential that produced the tokens, not the tokens already issued, unless the provider ties refresh token validity to the password or the responder revokes explicitly. Offboarding has the same gap: disabling the directory account may not reach tokens held by a third-party integration, which is a recurring theme in the Identity Breach Report 2026 list of credentials that should already have been dead.

How to detect it

  • Entra non-interactive sign-ins. Refresh token redemptions appear in AADNonInteractiveUserSignInLogs, not in the interactive SigninLogs most dashboards watch. Look for redemptions where IPAddress, AutonomousSystemNumber or UserAgent differ from the interactive sign-in that started the session, and use IncomingTokenType and UniqueTokenIdentifier to trace a token across requests. Entra ID Protection's anomalousToken detection explicitly covers refresh tokens.
  • Okta. app.oauth2.as.token.grant.refresh_token records each refresh grant. With refresh token rotation enabled, app.oauth2.as.token.detect_reuse (custom authorization servers) and app.oauth2.token.detect_reuse (org authorization server) fire when an already-rotated refresh token is presented again, which is the closest thing to a direct theft signal.
  • Google Workspace. The OAuth Token audit log records authorize events when a user grants an app access and activity events for API calls, each with client_id, app_name and the scopes or API used. Unfamiliar client IDs with high-volume activity events, or authorize events for broad mail or Drive scopes, are worth review.
  • SaaS integration logs. For connected apps, Google Threat Intelligence advised Salesforce customers after the Drift theft to review Event Monitoring logs for the integration's connection user, authentication activity from the connected app, and UniqueQuery events recording executed SOQL queries, and to search for the published user-agent strings.
  • Activity that survives a reset. Token refresh continuing at a normal cadence after a password reset or account lockout, which indicates the reset did not reach the standing tokens.

Be honest about the limits: legitimate refresh token use from a new IP happens constantly, when a user travels, changes networks, or uses a mobile device with a rotating carrier address, so IP change alone is a weak signal. Non-interactive sign-in volume is large enough that many organizations never ingest it, and that blind spot is where this technique lives. For integration tokens, the activity often comes from the vendor's own infrastructure, so there is no "unusual location" to see. The stronger signals are reuse detection, refresh activity that survives a credential reset, and bulk data access out of pattern for the integration.

How to stop it

  • Bind refresh tokens to the device or client. Entra Token Protection for sign-in session tokens, DPoP or mTLS for OAuth clients you build. RFC 9700 requires refresh tokens for public clients to be either sender-constrained or rotated.
  • Rotate on every use with reuse detection. Where the provider supports it, as Okta does with a configurable grace period, an old token presented again invalidates the family and flags a replay.
  • Revoke explicitly in incident response. In Entra, revokeSignInSessions invalidates all refresh tokens issued to applications for a user, along with browser session cookies, with a documented delay of a few minutes. Reset the password and revoke separately; neither does the other's job. Then remove unrecognized devices and MFA methods.
  • Govern who can grant offline access. Restrict user consent, require admin approval for high-privilege scopes, and block the device code flow where it is not needed, since those are the routes that mint long-lived tokens for an attacker.
  • Treat integrations as privileged non-human identities. Minimal scopes, IP restrictions on connected apps where the platform allows, short token lifetimes, an inventory of every connected app, and a tested way to revoke every token for one vendor in one action.
  • Use continuous access evaluation so a password change, account disable or risk event ends live tokens for supporting services instead of waiting out their lifetime. See CAEP.

Seen in the wild

Drift and Gainsight are both fan-out breaches in the Identity Breach Report 2026: one integration's tokens reaching many customers. Both sit in what the report calls the MFA blind zone, incidents with no interactive login for MFA to protect, which grew to 44% of 2025-2026 breaches (22 of 50).

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.