Access token vs refresh token risk: why MFA does not help

At a glance

What this is: This is a practitioner analysis of access token versus refresh token risk, showing that the real security difference is not authentication method but token lifetime and post-issuance abuse potential.

Why it matters: It matters because IAM teams that treat OAuth tokens as interchangeable credentials will miss the longer-dwell risk created by refresh tokens and the detection gap after MFA has already been satisfied.

By the numbers:

• Access tokens typically last 15 to 60 minutes, while refresh tokens enable persistent sessions lasting days to months.
• 60-90 minutes by default.

👉 Read Obsidian Security's analysis of access token and refresh token risk

Context

Access tokens and refresh tokens are both bearer credentials, but they create very different governance problems for IAM and NHI teams. The first is a short-lived authorization key for active use, while the second is a long-lived mechanism for session continuity. Once either token is issued, MFA no longer protects it, which means the main control question shifts from login assurance to token lifecycle control and monitoring.

That distinction matters because token theft turns into a post-authentication access problem, not a front-door login problem. In practice, this creates the same governance blind spot that appears across many NHI programs: the credential is valid, the actor is not, and conventional controls often lack the behavioral visibility to tell the difference. Teams looking for a broader framing should compare this problem with the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10.

The article's starting position is typical for SaaS environments that have already adopted SSO and MFA but have not extended governance to OAuth token behavior. That is a common maturity gap, not an edge case.

Key questions

Q: How should security teams handle stolen OAuth tokens when MFA is already in place?

A: Treat the incident as post-authentication access, not a login failure. MFA stops the initial sign-in, but it does not control token use after issuance. The response should focus on revocation, rotation, scope review, and behavioural monitoring across the affected SaaS applications because the token itself is the active credential.

Q: What is the difference between access token abuse and refresh token abuse?

A: Access token abuse is usually short-lived and noisy because the attacker has only minutes to act before expiry. Refresh token abuse is longer-lived and quieter because the attacker can keep minting new access tokens over days or months. The first is a sprint, the second is persistence.

Q: When does refresh token rotation become a priority control?

A: It becomes a priority wherever the organisation depends on persistent SaaS access, third-party integrations, or user sessions that must survive beyond a single login. Rotation matters most when compromise would create extended dwell time, because it gives defenders a replay signal and a way to break the token family.

Q: What should IAM teams monitor to detect OAuth token compromise?

A: Monitor token source networks, user agent changes, access timing, scope use, and unusual resource access over time. The key is to compare actual token behaviour with the expected baseline for that integration or user, because valid tokens often look legitimate until they start behaving differently.

Technical breakdown

Why access tokens and refresh tokens create different threat models

Access tokens are the working credentials presented to resource servers, so compromise creates immediate data access risk within a short validity window. Refresh tokens are sent only to the authorization server and are used to mint new access tokens, which makes them the persistence layer of OAuth sessions. Both are bearer tokens, so possession is enough for use. The security difference is therefore not whether MFA was used at login, but how long the stolen credential can keep producing valid access after initial issuance. That is why the same theft event can become a short incident or a long-running compromise.

Practical implication: Treat refresh tokens as persistent access assets and not as routine session artifacts.

How token rotation changes the abuse pattern

Refresh token rotation is a control pattern in which each refresh request returns a new refresh token and invalidates the previous one. If an old token is reused, the server can detect token-family reuse and revoke the chain. This matters because token families give defenders a way to collapse attacker dwell time after compromise is suspected. Without rotation, a stolen refresh token can remain effective until manual revocation. With rotation, the attacker must keep pace with the legitimate client and risk detection when reuse occurs. The control reduces the value of any single stolen token and creates an explicit replay signal.

Practical implication: Enable rotation wherever the client and identity platform support it, then alert on reuse.

Why behavioural detection matters more than static inventory

Static token inventories show what exists, but not whether a valid token is being abused. A stolen access token may generate a burst of unusual activity quickly, but a stolen refresh token can blend into normal refresh cadence and app usage for weeks. That makes point-in-time detection and volume thresholds insufficient. Security teams need baselines for source network, user agent, access timing, scope use, and resource patterns. In OAuth environments, the best signal is often deviation from normal token behaviour over time, not the token itself.

Practical implication: Build detection around token behaviour baselines, not token counts alone.

Threat narrative

Attacker objective: The attacker wants durable, low-friction access to SaaS data and connected workflows without triggering login-based controls.

1. Entry occurs when an attacker obtains an OAuth access token or refresh token through theft, logging exposure, browser storage compromise, or third-party integration abuse.
2. Escalation occurs when the attacker uses the token to obtain repeated access, request new access tokens, or blend into expected SaaS activity patterns while avoiding MFA.
3. Impact occurs when the attacker exfiltrates data or maintains long-lived access across connected applications without needing to reauthenticate.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bearer-token governance is now a core NHI problem, not just an application security detail. OAuth access and refresh tokens behave like non-human identities because they can act independently of the human who approved them. That means IAM teams cannot limit their attention to sign-in events and consent screens. The governance problem extends into token lifetime, reuse, and behavioural monitoring, which is where most SaaS environments remain weak. Practitioners should treat token issuance as the start of control, not the end of it.

Ephemeral access does not eliminate trust debt. Short-lived access tokens reduce exposure, but they do not resolve the trust assumption that the bearer is still legitimate. That trust debt becomes more visible when refresh tokens can silently extend access for months. The field should stop equating short expiry with safety and instead measure whether the organisation can detect abuse inside the valid window. Practitioners should align controls to blast radius, not just expiration time.

Refresh token rotation is the practical dividing line between manageable and indefinite compromise. Rotation converts replay into a detectable event and makes token family revocation possible. Without it, the environment relies on manual revocation and hope. With it, defenders get a machine-readable indicator that access has been reused incorrectly. Practitioners should make rotation a default requirement for high-risk SaaS integrations and user-facing applications.

Identity teams need a dedicated token abuse control plane. Traditional IAM, MFA, and SSO controls are necessary but insufficient once OAuth credentials exist outside the login path. This topic shows why NHI governance must include token inventory, behavioural telemetry, and response playbooks for abuse. Practitioners should build policies that cover issuance, rotation, revocation, and anomaly detection as one lifecycle.

Access token versus refresh token risk is a useful named concept for programme design. The useful distinction is not technical trivia, it is an operational boundary between short-window misuse and long-window persistence. Once teams see tokens through that lens, incident response, monitoring, and access reviews become more accurate. Practitioners should map controls to the persistence profile, not the protocol label.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why token and secret abuse often persists after policy exists on paper.
• That same gap makes NHI Lifecycle Management Guide the next resource to consult when teams need to move from inventory to enforceable rotation and offboarding.

What this signals

Access token versus refresh token risk will become a standard design question in SaaS governance because attackers increasingly target the session layer after MFA has already succeeded. Teams that still rely on login-centric controls will continue to miss abuse that looks legitimate at the authentication boundary. Practitioners should expect token telemetry to become a normal part of identity operations, not a specialist add-on.

With the average estimated time to remediate a leaked secret at 27 days according to The State of Secrets in AppSec, the practical lesson is that response latency can easily exceed the useful life of an exposed credential. That is why monitoring and automated revocation have to sit closer to the control plane than manual review does.

Token persistence debt: the longer a refresh token can survive, the more the organisation owes in monitoring, rotation, and revocation discipline. The same logic applies to SaaS integrations, where legitimate automation can mask attacker activity until the blast radius is already large. Practitioners should start measuring how quickly they can invalidate a compromised token family, not just how many tokens they can count.

For practitioners

• Implement refresh token rotation by default Require rotation for integrations and applications that support it, and invalidate the token family when reuse is detected so a stolen token cannot remain useful indefinitely.
• Baseline token behaviour across SaaS workloads Track source network, user agent, access timing, and resource patterns so token misuse stands out against normal activity rather than disappearing into legitimate automation.
• Separate short-window and long-window detection logic Use different alert thresholds for access tokens and refresh tokens because a 30-minute theft behaves differently from a months-long persistence threat.
• Review OAuth scope exposure and blast radius Map which applications can mint or reuse tokens, which datasets those tokens touch, and where overprivilege creates a larger impact if one token is stolen.

Key takeaways

• Access tokens and refresh tokens create different abuse windows, so one detection model will not cover both.
• MFA protects the login event, but once OAuth tokens exist the governing question becomes lifetime, reuse, and behavioural drift.
• Programmes that add token rotation, behavioural baselines, and fast revocation are better positioned to contain post-authentication abuse.

Key terms

• Access Token: A short-lived bearer credential that lets a client call a protected resource on behalf of an authenticated user or workload. It is designed for immediate use, not long-term persistence, which is why theft creates a compressed but still serious abuse window.
• Refresh Token: A long-lived bearer credential used to obtain new access tokens without forcing the user to sign in again. It extends session continuity and is therefore a higher-value target, because compromise can turn a brief intrusion into sustained access over time.
• Token Family: A chain of related refresh tokens issued through rotation, where each new token replaces the prior one. If an old token is reused, the server can treat the event as compromise or client failure and invalidate the family to stop indefinite access.
• Token Behaviour Baseline: A profile of normal token use built from source network, timing, user agent, scopes, and resource access patterns. It helps defenders spot abuse of otherwise valid credentials by comparing actual usage with expected behaviour over time.

Deepen your knowledge

Access token and refresh token governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a token control programme for SaaS and OAuth environments, it is worth exploring.

This post draws on content published by Obsidian Security: Access Token vs Refresh Token: Key Differences Explained. Read the original.