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

At a glance

What this is: This is a Descope guide comparing OAuth access tokens and refresh tokens, with the key point that short-lived access tokens and longer-lived refresh tokens serve different session and security functions.

Why it matters: It matters to IAM practitioners because token lifetime, storage, and rotation choices affect human login flow, NHI-style service access, and any future agent-driven session model that depends on bearer credentials.

By the numbers:

• Access token lifespans in Microsoft’s identity platform are between 30-90 minutes by default.
• Refresh tokens in Microsoft’s identity platform have default and rigid lifespans of 90 days for most scenarios and 24 hours for single-page apps.

👉 Read Descope's guide to access tokens and refresh tokens in OAuth

Context

OAuth uses tokens instead of traditional passwords to let a client prove authenticated access to a resource server. In practice, the key governance issue is not just how tokens work, but which identity assumptions they embed about session duration, revocation, and where the credential material lives.

For IAM teams, the real question is how bearer-style access behaves once it is stored in browser memory, cookies, or an authorization server. That matters across human authentication, workload access, and any NHI programme that relies on short-lived credentials and refresh-based continuity.

Key questions

Q: How should security teams choose between short-lived access tokens and refresh tokens?

A: Use short-lived access tokens when re-authentication is acceptable and the resource is sensitive. Add refresh tokens when the business needs persistent sessions, but pair them with secure storage, narrow scopes, and rotation so longevity does not become durable abuse potential.

Q: Why do refresh tokens create more governance risk than access tokens?

A: Refresh tokens extend access across multiple token renewals, so compromise can outlast a single login session. Their longer lifetime makes lifecycle control, revocation, and secure storage more important than with short-lived access tokens.

Q: What breaks when access tokens are stored insecurely in the browser?

A: If script-accessible storage is exposed, an attacker who gains page or device-level access can steal the token and replay it until expiry. That defeats the assumption that authentication is confined to the intended session and turns browser compromise into resource compromise.

Q: Who should own refresh-token revocation when access changes?

A: Identity and application owners should share responsibility, because revocation is part of the authorization lifecycle, not just an application event. Offboarding, consent changes, and policy updates should invalidate refresh tokens immediately so old sessions do not persist.

Technical breakdown

Access tokens and bearer semantics

An access token is a short-lived credential that authorises a client to call a protected resource without re-entering the user’s primary secret. Most access tokens act as bearer tokens, which means possession is enough to use them until expiry or revocation. That makes storage location and transport path critical. If the token sits in browser memory or another exposed client-side location, the attacker does not need the original login ceremony. The security model depends on short lifetime, limited scope, and TLS-protected transport, not on the token being inherently trustworthy.

Practical implication: keep access-token scope narrow and treat client-side storage as a control boundary, not a convenience detail.

Refresh tokens, session continuity, and rotation

A refresh token exists to obtain a new access token after the original one expires. It is longer-lived, usually more sensitive from a lifecycle perspective, and often stored on the authorization server rather than the client. That design supports persistent sessions without repeated logins, but it also extends the window in which a stolen refresh token can be abused. Rotation changes the risk profile by invalidating the old refresh token when a new one is issued, reducing replay value if the token is captured after use.

Practical implication: apply refresh-token rotation wherever long-lived sessions are unavoidable, especially for SPA and mobile access patterns.

OAuth and OIDC in passwordless access flows

OAuth handles delegated authorization, while OpenID Connect adds the identity layer for authentication. In passwordless or federated flows, tokens become the mechanism that preserves session state after the initial trust decision. That makes token issuance policy central to governance: the auth server becomes the control point for re-authorization, refresh, and revocation. The architecture is efficient, but it shifts risk from repeated password checks to the management of bearer credentials and the assumptions embedded in token validity windows.

Practical implication: align token policy, revocation logic, and storage controls across OAuth and OIDC rather than treating them as separate problems.

Threat narrative

Attacker objective: The attacker aims to sustain authenticated access after the initial token should have expired, allowing continued use of protected resources without the legitimate user’s involvement.

1. Entry occurs when an attacker obtains a bearer token or refresh token from an exposed client, weak storage location, or intercepted session flow.
2. Escalation follows when the stolen token is reused to mint new access tokens or extend the session without re-authenticating the original identity.
3. Impact is achieved when the attacker maintains access to protected resources for longer than the original access token lifetime allowed.

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 depends on where possession can be transferred. Access tokens are not just session artefacts. They are transferable proof of access, so the security model collapses if the client-side storage boundary is weak or the transport path is not tightly controlled. For IAM programmes, the issue is not token format alone but whether possession equals authority in ways the business can tolerate.

Refresh-token rotation is a lifecycle control, not a user-experience tweak. The guide correctly frames rotation as a way to reduce reuse of older refresh tokens, but the deeper governance point is that refresh tokens create persistent identity continuity across multiple access-token lifecycles. That makes them closer to an NHI lifecycle problem than a one-time login event. Practitioners should read this as a control over persistence, revocation, and replay value.

Access and refresh tokens expose the limits of static session design in zero trust environments. Zero trust assumes continuous verification, yet bearer tokens deliberately preserve access across time gaps. That creates a tension between frictionless sessions and re-authentication discipline. The implication is that session policy, token lifetime, and revocation speed must be governed as one trust boundary, not as separate settings in different teams.

Token lifetime is a governance decision about blast radius. Short access-token lifespans reduce exposure, while longer refresh-token lifespans preserve usability. The article’s guidance points to a structural trade-off that identity teams often understate: the longer the continuity window, the more important revocation, detection, and secure storage become. Practitioners should treat lifetime policy as part of risk appetite, not just implementation detail.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• The same report says 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For the broader token and access conversation, the Ultimate Guide to NHIs is the next step for lifecycle, visibility, and governance context.

What this signals

Ephemeral access is only useful when the organisation can prove where it lives and when it dies. The token model in this article is familiar, but the operational pressure is rising as more identity workloads become machine-driven. As AI agents and service identities inherit the same bearer-token patterns, token storage, revocation, and lifecycle events become shared governance concerns across IAM, PAM, and NHI programmes.

Session continuity is becoming a governance surface, not just an auth feature. The more organisations rely on long-lived refresh semantics, the more they need a clear control boundary between usability and persistence. That is especially true when session state spans human access, workload identity, and agent-driven automation.

As deployment density rises, the practical question is no longer whether tokens should be short or long lived. It is whether the programme can still explain which identity is authorised, which token can renew it, and which event ends it. That is where bearer-token governance becomes an identity lifecycle problem, not a login design choice.

For practitioners

• Tighten access-token scope and lifetime Set the shortest practical expiry for resource access, then validate that scopes map only to the specific API or session purpose. Revisit defaults wherever high-sensitivity data or privileged actions are involved.
• Apply refresh-token rotation where sessions persist Use one-time refresh semantics so a newly issued token invalidates the previous one. That reduces replay value and makes stolen refresh tokens less useful after legitimate use.
• Secure client-side token storage Prefer HTTP-only cookies or equivalent protected storage patterns over local storage for browser-based apps, and avoid exposing bearer material to script-accessible locations.
• Align revocation with identity lifecycle events Tie refresh-token invalidation to offboarding, consent withdrawal, and application access changes so persistent sessions do not outlive the identity decision that granted them.

Key takeaways

• Access and refresh tokens solve different problems, but both turn token lifetime into an identity governance decision.
• Short-lived access tokens reduce exposure, while refresh tokens extend risk unless storage, rotation, and revocation are tightly controlled.
• Identity teams should treat token policy as part of lifecycle governance across human sessions, workloads, and emerging AI-driven access paths.

Key terms

• Access Token: A short-lived credential that authorises a client to access a protected resource after successful authentication. In practice, it behaves like a bearer proof of access, so whoever holds it can use it until it expires or is revoked. That makes scope, storage, and transport critical governance concerns.
• Refresh Token: A longer-lived credential used to obtain a new access token when the original one expires. It supports session continuity without repeated logins, but it also creates a longer abuse window if stolen. For identity teams, it is a lifecycle control because it governs persistence across multiple access events.
• Bearer Token: A token that grants access based on possession rather than on an additional proof step at request time. If an attacker obtains it, they can often replay it until the token expires. This makes bearer-token handling a storage and revocation problem as much as an authentication problem.
• Token Rotation: The practice of issuing a replacement token and invalidating the previous one when refresh occurs. It reduces replay value if a token is captured after use and is especially important when sessions are expected to last a long time. Rotation is a lifecycle safeguard, not a cosmetic hardening step.

What's in the full article

Descope's full guide covers the operational detail this post intentionally leaves for the source:

• Microsoft token default ranges and how they affect session design in practice
• A step-by-step OAuth refresh flow for implementation teams that need to wire the auth server correctly
• Rotation and revocation considerations for teams deciding how to reduce refresh-token replay risk
• Storage guidance for browser-based applications that need to keep bearer tokens out of script-accessible locations

👉 Descope's full post covers the token refresh flow, storage choices, and rotation guidance in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.