Access tokens vs refresh tokens: what IAM teams need to weigh

At a glance

What this is: This guide breaks down how access tokens and refresh tokens work together in OAuth and OIDC, and shows why their different lifetimes, storage models and rotation behavior create different IAM risks.

Why it matters: IAM teams need to separate session continuity from credential exposure because token design choices directly affect attack surface, revocation behavior and user reauthentication pressure.

By the numbers:

• Microsoft’s identity platform uses access token lifespans between 30 and 90 minutes by default.
• Microsoft’s identity platform gives most refresh tokens a default lifespan of 90 days.
• Single-page apps get refresh token lifespans of 24 hours in Microsoft’s identity platform.

Context

OAuth 2.0 and OpenID Connect rely on tokens rather than reusable credentials to grant access to resources. In this model, access tokens carry the immediate authorisation decision, while refresh tokens keep the session alive by asking the authorization server for a new access token when the current one expires.

For IAM teams, the practical question is not whether tokens are convenient. It is whether the programme can govern token lifetime, token storage and refresh behavior without creating a longer-lived exposure path than the business actually needs.

The article’s examples make this a session-governance issue, not just a login-flow choice. Short-lived access tokens narrow the exposure window, while refresh tokens shift risk into rotation, revocation and secure storage controls.

Key questions

Q: When should organisations rely on access tokens without refresh tokens?

A: Use access tokens alone when sessions are deliberately short, user reauthentication is acceptable, and the application does not need persistent continuity. That is common in high-security internal tools or tightly controlled workflows. The point is not to avoid refresh tokens entirely, but to reserve them for cases where the business genuinely needs longer session continuity.

Q: When does refresh token design become a governance problem?

A: Refresh token design becomes a governance problem when renewal outlives the access conditions that justified it. If role changes, partner offboarding, or risk elevation do not narrow refresh behaviour, the token lifecycle continues after trust should have been reduced. At that point, renewal is extending exposure rather than preserving usability.

Q: What are the signs that token policy is too permissive?

A: Common signs include very long refresh-token lifespans, broad scopes, client-side storage that exposes tokens to browsers or scripts, and a lack of rotation when new access tokens are issued. If any of those are present, the programme is optimising convenience faster than it is containing exposure.

Q: How should IAM teams balance user experience and token security?

A: They should separate convenience from trust. Short access-token lifetimes and secure refresh flows can preserve a reasonable user experience without allowing unrestricted session persistence. The right balance is the one that still lets the organization revoke access quickly and prevent a stolen token from becoming a durable credential.

Technical breakdown

How access tokens carry resource access

An access token is the artifact a client presents to a resource server after successful authorization. In OAuth flows, the token proves the user has already been approved, and in many implementations it is a JWT or bearer token that can be accepted until it expires. Because it is meant for immediate use, the security model depends on short lifespan, limited scope and safe client-side handling. The article notes that access tokens are often stored in HTTP-only cookies or browser memory, which reduces some theft paths but does not change the fact that whoever holds the token can use it until expiry.

Practical implication: treat access-token lifetime and scope as enforceable policy decisions, not convenience settings.

How refresh tokens extend sessions

A refresh token does not access the resource directly. Instead, it is presented to the authorization server after the access token expires, and the server validates it before issuing a new access token. That makes the refresh token a session-continuity mechanism, not a resource credential. The longer lifespan is the trade-off: it improves user experience and reduces repeated login prompts, but it also increases the value of secure storage, revocation logic and rotation. The guide’s point is that refresh tokens are useful precisely because they reintroduce the trust decision at revalidation time.

Practical implication: place refresh-token controls on the authorization server side and tighten revocation and rotation there.

Why rotation changes the refresh-token risk model

Refresh token rotation replaces the old token each time a new access token is issued and invalidates the previous refresh token. That matters because refresh tokens are otherwise the long-lived anchor in the flow. Rotation does not remove exposure, but it narrows the window in which a stolen refresh token remains useful and makes abuse easier to detect. The article frames rotation as especially relevant when sessions are long or when old refresh tokens are more likely to be stolen or reused. In governance terms, rotation is the control that stops the session from becoming a durable privilege path.

Practical implication: make rotation mandatory wherever long-lived sessions are allowed.

Threat narrative

Attacker objective: The attacker wants to turn a single stolen token into continued access without needing the user’s password or repeated authentication.

1. Entry occurs when a stolen or exposed token is reused in place of a password, because bearer-style tokens can be accepted by the resource or authorization server if still valid.
2. Escalation happens when a refresh token remains active long enough to mint new access tokens, extending the attacker’s usable session beyond the original access-token window.
3. Impact is durable unauthorized access to protected resources without repeated user login, especially where storage or rotation controls are weak.

Breaches seen in the wild

• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
• Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.

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

NHI Mgmt Group analysis

Access-token lifetime is a session-control problem disguised as an authentication detail. The article shows that the security value of a short-lived access token is really about limiting how long a bearer credential can be misused. That makes expiry, scope and storage the three governance levers that matter most. Practitioners should stop treating access-token duration as a UI choice and start treating it as an authorization boundary.

Refresh-token governance creates a longer-lived trust obligation than many IAM programmes admit. A refresh token is not a simple extension of login convenience. It is the mechanism that keeps reissuing access after the original session has expired, which means revocation and rotation must be reliable enough to interrupt abuse after compromise. The practical conclusion is that session continuity is only safe when the revalidation path is governed as tightly as the initial login.

Ephemeral access does not eliminate credential risk when the refresh path stays durable. The article’s core distinction is that access tokens reduce immediate exposure, while refresh tokens preserve continuity. That produces a governance asymmetry: the shorter-lived token is easy to explain, but the longer-lived token is where control debt accumulates. IAM teams should assess token policy as a lifecycle problem, not as two separate token types.

Token containment, not token type, is the named control problem. The real issue is whether a stolen token remains useful after first use. If refresh tokens are not rotated or if access tokens are stored in ways that expand client-side exposure, the session becomes a reusable trust path instead of a bounded authorization event. Practitioners need policy that enforces containment at issuance, storage and refresh, not just at authentication.

OAuth and OIDC token design is now part of identity blast-radius management. In modern IAM, a compromised token should not behave like a reusable master key. The article reinforces that shortest-possible lifetime, narrow scope and controlled refresh are the mechanisms that limit blast radius. The practitioner takeaway is simple: design token policy around abuse containment, not around uninterrupted convenience.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Token policy is becoming a lifecycle governance issue, not a configuration detail. When access and refresh tokens are treated as separate but related controls, IAM teams can place one on immediate access and the other on session continuation. That split matters because the control that limits exposure is not the same control that preserves usability.

Short-lived access tokens only solve half the problem. The enduring risk sits in the refresh path, where a longer-lived credential can keep reissuing access after the original token expires. For practitioners, the next step is to decide which applications can tolerate reauthentication and which ones require rotation-backed session continuity.

For practitioners

• Set separate lifetimes for access and refresh tokens Use the shortest access-token lifetime that the business can tolerate, then define refresh-token duration as a distinct policy decision rather than a default extension of the session.
• Constrain token scope to the minimum resource set Limit each token to the smallest set of resources and actions required, so a stolen token cannot pivot into unrelated application paths or broader user entitlements.
• Store refresh tokens on the server side wherever possible Prefer authorization-server storage for refresh tokens and avoid client-side persistence patterns that expand theft risk in browsers, scripts or shared devices.
• Make refresh-token rotation the default Invalidate the previous refresh token every time a new one is issued, so stolen tokens age out quickly and reuse attempts become easier to block.
• Revisit token policy for long-lived sessions Review mobile apps, SPAs and B2B portals separately, because persistent user sessions often need tighter refresh governance than internal tools or short-duration access flows.

Key takeaways

• Access tokens and refresh tokens solve different problems, and treating them as interchangeable weakens governance over session risk.
• The key exposure question is not just how long access lasts, but how long a refresh path can keep extending it.
• IAM teams should set token lifetime, storage and rotation policies as a single control family, not as separate implementation choices.

Key terms

• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Token Rotation: Token rotation is the practice of replacing a refresh token with a new one after use and invalidating the previous token. It helps detect replay and reduces reuse risk, but it does not solve compromise on its own. Strong implementations combine rotation with atomic invalidation, telemetry, and full-family revocation.
• Session Continuity: Session continuity is the ability to preserve a user's authenticated state as they move between devices or locations without forcing a full re-login. In clinical environments, it reduces interruptions while still allowing lock, timeout, and revalidation controls to protect the session when risk changes.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.