How should security teams implement OAuth in single page applications without exposing tokens in the browser?

Use a backend for frontend pattern, or a Token Handler, so the browser never directly stores long lived access tokens. The back end handles OAuth interactions with the authorization server, keeps tokens in a safer server side context, and exposes only what the SPA needs through browser security controls. This preserves SPA usability while reducing token theft risk.

Why This Matters for Security Teams

SPAs are attractive because they reduce page reloads and keep user experience smooth, but the same browser context that makes them fast also makes token handling fragile. When OAuth access tokens or refresh tokens live in the browser, they become reachable to XSS, malicious extensions, injected scripts, and session replay. That changes OAuth from an application integration problem into a browser compromise problem, especially when the app can reach sensitive SaaS or internal APIs through third-party connections.

NHIMG research shows how often OAuth visibility breaks down in practice: The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means token exposure is often only discovered after an incident. That pattern matches real breaches such as the Salesloft OAuth token breach, where token misuse became the path to downstream data access. For browser-based apps, the security question is not whether OAuth works, but where the tokens should ever be allowed to exist.

In practice, many security teams discover browser token exposure only after a session has already been replayed or a connected app has already been abused.

How It Works in Practice

The most common secure pattern is a backend for frontend, or BFF, sometimes implemented as a token handler. The browser authenticates to the application, but OAuth code exchange, token storage, refresh, and downstream API calls happen on the server side. The browser receives only a session cookie or a narrowly scoped browser session artifact, while the backend holds the access token and refresh token in a controlled server-side context.

This design reduces the blast radius of browser compromise because the token is never placed in JavaScript-accessible storage such as localStorage or sessionStorage. It also makes it easier to enforce CSRF protections, SameSite cookies, short-lived sessions, and per-request authorization checks. For implementation guidance, security teams should align this with modern OAuth best practice and token handling guidance from RFC 9700, OAuth 2.0 Security Best Current Practice, which reinforces avoiding unsafe browser token exposure paths. For operational controls around secrets and authorization hardening, NIST SP 800-53 Rev. 5 remains a useful control baseline.

• Keep OAuth client credentials and refresh tokens off the client runtime entirely.
• Use the backend to exchange authorization codes and to call downstream APIs.
• Issue short-lived browser sessions and rotate them aggressively.
• Bind session cookies with HttpOnly, Secure, and SameSite controls where applicable.
• Apply least privilege to each OAuth scope and revalidate access when the session changes.

NHIMG’s 52 NHI Breaches Analysis and Guide to the Secret Sprawl Challenge both illustrate the same operational lesson: once a token is exposed in a broad client context, revocation is harder and detection is slower. These controls tend to break down in highly distributed front ends that mix multiple IdPs, embed third-party scripts, or depend on direct browser-to-API calls because token lineage becomes difficult to govern consistently.

Common Variations and Edge Cases

Tighter browser token controls often increase backend complexity and can add latency, so organisations have to balance user experience against exposure reduction. There is no universal standard for every SPA architecture yet, especially when teams need offline access, embedded widgets, or cross-domain integrations.

One common variation is a pure API gateway pattern, where the SPA still talks to an intermediary that enforces policy and removes direct token handling from the browser. Another is a split-token model, where the browser holds only a minimal, short-lived proof artifact while the backend retains refresh capability. Current guidance suggests that any design allowing long-lived tokens in browser storage should be treated as an exception, not a default. That is especially true when apps load third-party JavaScript, support federated SaaS access, or depend on user-installed extensions, since those environments increase the chance of token theft even when the SPA itself is well built.

Teams should also watch for consent sprawl. OAuth scopes that looked reasonable at launch can become excessive as product requirements expand, and a broad token is still a broad token even if it is hidden behind a polished interface. The State of Non-Human Identity Security shows how quickly OAuth-linked third-party access becomes opaque once organisations scale, which is why regular review of connected apps, scopes, and revocation paths matters as much as initial architecture.

Related resources from NHI Mgmt Group

• How should security teams test single-page applications without relying on browser crawling?
• How should security teams implement OAuth device flow for CLI tools without creating new credential risks?
• How should security teams implement social login without exposing OAuth secrets?
• How should security teams implement AI agent onboarding without relying on browser-based OAuth redirects?