How should security teams handle refresh tokens in single-page applications that run in the browser?

Why This Matters for Security Teams

Browser-based refresh tokens are not ordinary session artifacts. In a single-page application, they often become the easiest path to long-lived API access if they are stored, copied, or reused in ways the browser can expose. That shifts the risk from “token theft is possible” to “token theft is operationally attractive,” especially when the same token can be replayed across sessions or devices.

Current guidance suggests treating refresh tokens as high-value credentials, not as convenience data. A browser is a hostile runtime by default: extensions, XSS, misconfigured storage, and debugging tools all increase exposure. This is why NIST SP 800-53 Rev 5 Security and Privacy Controls continues to matter for session management, while NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly sensitive tokens spread once they leave tightly controlled handling paths.

In practice, many security teams discover refresh token abuse only after a browser-side compromise has already turned a single session into sustained access.

How It Works in Practice

The safest pattern for a SPA is to minimise what the browser can hold and how long it can hold it. Use Authorization Code flow with PKCE, keep access tokens short-lived, and rotate refresh tokens on every use so a stolen token becomes harder to replay. If the application has meaningful business or regulatory sensitivity, move the most sensitive token work server side with a backend-for-frontend, so the browser never directly handles the long-lived credential.

That design also supports stronger containment when a token is exposed. A BFF can centralise token exchange, apply server-side session policy, and enforce revocation logic without depending on client-side storage discipline. Where browser storage is unavoidable, the question is not just “where is the token stored?” but “what conditions must be true before it can be used again?” Runtime evaluation matters because refresh tokens are effectively bearer secrets unless the surrounding controls narrow that exposure.

Salesloft OAuth token breach is a useful reminder that OAuth tokens become lateral movement assets when they are over-trusted. For implementation detail, OAuth’s security posture is strongest when paired with PKCE, token rotation, and strict storage boundaries, as described in OAuth 2.0 Security Best Current Practice. If browser storage is used at all, it should be treated as a constrained exception rather than the default architecture.

• Use short token lifetimes and rotate refresh tokens on use.
• Prefer server-side token handling via a backend-for-frontend for sensitive apps.
• Keep tokens out of local storage when a safer session design is available.
• Bind session renewal to server-side policy, not only client behaviour.

These controls tend to break down when teams need offline-capable browser sessions with no reliable server-side session authority, because token lifecycle enforcement becomes much harder to trust end to end.

Common Variations and Edge Cases

Tighter refresh token controls often increase implementation complexity and operational overhead, requiring organisations to balance security gain against user experience and support burden. That tradeoff is real, especially when apps must survive tab refreshes, intermittent connectivity, or cross-domain login flows.

There is no universal standard for every SPA pattern yet, but best practice is evolving toward the least browser exposure possible. For lower-risk internal apps, a well-designed SPA may accept browser-side token use with aggressive rotation and narrow scopes. For customer-facing or regulated workloads, a BFF or equivalent token broker is usually the stronger design. The distinction is not cosmetic: once a refresh token exists in the browser, the threat model changes from ordinary session management to credential protection.

NHIMG’s coverage of the 2025 State of NHIs and Secrets in Cybersecurity highlights how often tokens remain active far longer than teams expect, which is exactly why lifecycle controls must be deliberate. If the same session model is also used for partner integrations or automation, the browser path should be revisited alongside Internet Archive breach lessons on long-lived credential exposure.

Guidance becomes less decisive when the application must support multi-tab continuity, mobile-web handoff, or legacy identity providers, because the safest architecture can conflict with product requirements.

Related resources from NHI Mgmt Group

• How should security teams implement OAuth in single page applications without exposing tokens in the browser?
• How should security teams test single-page applications without relying on browser crawling?
• How should security teams handle OAuth tokens in multi-API applications?
• How should security teams handle cloned login page attacks in the browser?