how to store OAuth tokens securely in a single-page app

TL;DR

Do not put long-lived OAuth tokens in localStorage or sessionStorage: any XSS hole in your app hands them to the attacker. The standard safe pattern is short-lived access tokens kept in memory plus a refresh token in an httpOnly, Secure, SameSite cookie that JavaScript cant read. If you can run a backend, the backend-for-frontend pattern is even better because tokens never reach the browser at all.

how to store OAuth tokens securely in a single-page app

Use this when

• You are building login for a React/Vue/Angular app and need somewhere to keep tokens
• A pentest or code review flagged access tokens sitting in localStorage
• You are deciding between cookie-based and token-based sessions for an SPA
• You need to explain the tradeoff to a teammate

Not for

• Storing tokens in native mobile apps (use the OS keychain/keystore)
• Server-side session stores (different threat model)
• Choosing an OAuth grant type or provider

Steps

1. Accept the core tradeoff. localStorage is readable by any JavaScript on your page, so it is only as safe as your XSS defenses. An httpOnly cookie is invisible to JavaScript, so it survives an XSS hole but needs CSRF protection. Plan around both threats, not just one. Expected output: a written decision (even one paragraph) naming where each token lives and why.

2. Keep the access token in memory. Store it in a JS variable or closure, request it with a short lifetime (5-15 minutes), and accept that a page reload means re-authenticating or silently refreshing. Short lifetime bounds the damage if one leaks. Expected output: closing and reopening the tab drops the access token; the app re-fetches it without user friction.

3. Put the refresh token in an httpOnly, Secure, SameSite cookie. Your backend issues it with the HttpOnly, Secure, and SameSite=Lax (or Strict) flags so JavaScript cant read it and browsers only send it to your own origin. Rotate the refresh token on every use (reuse detection) and bind it to the client where your provider supports it. Expected output: document.cookie in devtools never shows the refresh token, and each refresh returns a new one.

4. Add CSRF protection for the cookie-based refresh. Because the browser attaches the cookie automatically, require a custom header or a same-site check on the refresh endpoint. SameSite=Lax stops most cross-site POST abuse, but the header check closes the gap. Expected output: a cross-origin form POST to the refresh endpoint fails while your own app succeeds.

5. Consider backend-for-frontend if you run a backend at all. The browser holds only a plain session cookie; the BFF keeps the OAuth tokens server-side and attaches them to upstream calls. This removes token storage from the browser entirely. Expected output: no OAuth tokens appear anywhere in browser storage or devtools network tab.

6. Log and monitor token misuse. Alert on refresh-token reuse (it signals theft), impossible-travel logins, and refresh storms from one client. Revoke and force re-login on suspicion. Expected output: a test with a reused refresh token triggers an alert and invalidates the token family.

Variant phrasings

• "is it safe to store JWT in localStorage"
• "SPA refresh token httpOnly cookie pattern"
• "where should I keep OAuth access token in browser"
• "BFF pattern vs localStorage tokens"

Edge cases and pitfalls

• Silent refresh in an iframe breaks under some third-party-cookie restrictions; the BFF pattern avoids this class of problem entirely.
• Mobile WebViews and some embedded browsers handle SameSite cookies oddly, so test your target browsers, not just desktop Chrome.
• Memory storage dies on reload, which annoys users; that is the price of the security, and silent refresh is the accepted way to hide it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CtyZm3g5w-8EkwC-J1PNZw