In-memory storage keeps the token only while the page session is active, so it disappears on refresh or tab close. Local storage persists the token across reloads, which improves continuity but increases exposure if the browser context is compromised. Choose the first for short-lived sessions and the second only when persistence is needed and the environment is controlled.
Why the Storage Choice Changes Your Risk Profile
The difference is not just where the token sits, it is what kind of failure you are willing to tolerate. In-memory storage reduces persistence and narrows the window for token reuse after a browser restart, but it can disappear unexpectedly and force reauthentication. Local storage improves continuity across reloads and tab closes, but it also makes the token available to anything running in the browser context, which raises the impact of script injection and other client-side compromise paths.
For authentication SDKs, that trade-off matters because the token is usually a bearer credential, so possession is enough to act. That means the storage decision changes blast radius, session durability, and how aggressively you must trust the browser environment. Security teams often treat this as a UI convenience choice, then discover the real issue only after a token has been copied out of the browser context.
When teams want a control baseline for broader browser-side protection, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for anchoring access control, logging, and session protections around the application that consumes the token.
How It Works in Practice
In-memory storage keeps the token inside JavaScript runtime state, so it exists only while the page or tab remains alive. That makes it a better fit for short-lived sessions, rapid reauthentication, and cases where you want the token to vanish as soon as the page context is lost. The downside is operational: reloads, crashes, multi-tab usage, and navigation events can all interrupt the session and force the SDK to acquire a fresh token.
Local storage persists data in the browser profile, so the SDK can restore the token after refresh or browser restart. That improves user continuity, especially in long-lived workflows, but it also means any script with access to the page origin can usually read the token. If the application suffers cross-site scripting, malicious extension activity, or another browser-context compromise, the token can be harvested and replayed until it expires or is revoked.
- Use in-memory storage when session continuity can be brief and reauthentication is acceptable.
- Use local storage only when persistence is a functional requirement and the browser environment is tightly controlled.
- Keep token lifetime short enough that persistence does not become indefinite exposure.
- Prefer additional hardening on the application side, because storage choice alone does not prevent client-side compromise.
That trade-off is easy to underestimate in SPAs, where the most common breakage is not the token disappearing, but the assumption that browser-side persistence is harmless in an origin that already runs third-party scripts and dynamic content.
Common Variations and Edge Cases
Tighter persistence control often increases user friction, so teams have to balance session convenience against exposure. In practice, the right choice depends on token value, session length, refresh strategy, and how much trust the browser context truly deserves.
Some SDKs split access and refresh behaviour, using a short-lived in-memory access token with a separate renewal path that is handled more carefully. That pattern can reduce how long a stolen token remains useful, but it only works if refresh handling is equally protected and the application can tolerate the added complexity. Other environments, such as kiosk-style deployments or managed enterprise browsers, may justify local storage because the client machine itself is locked down and session persistence is operationally important.
There is no universal standard that says one storage method is always correct. The practical test is whether the token’s value and lifespan exceed the trust level of the browser context. If they do, persistence should be treated as a deliberate exception, not the default.
Risk and Threat Considerations
The main risk is bearer-token exposure in the browser, where anything that can run in the origin can often reach local storage. That creates a durable credential theft problem rather than a transient session problem, especially when the token remains valid long enough to be replayed.
Failure mechanism: A script injection, malicious extension, or compromised page context can read local storage directly and exfiltrate the token. In-memory storage reduces that persistence, but it does not protect against active compromise while the page is open.
Impact: The attacker gains authenticated access until the token expires or is revoked, which can expose user data, API access, and downstream systems that trust the token.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Token storage affects authentication state and access to the application. |
| PR.DS-1 — Data-at-Rest Protection | Local storage persists bearer tokens on the client device. | |
| Recommendation — Limit token scope and lifetime to reduce replay exposure from browser-side compromise. Avoid persisting bearer tokens in browser storage unless the client is tightly controlled. | ||
| CIS Controls v8 | 6.3 — Access Rights Management | Session tokens function as access rights and need tight lifecycle control. |
| Recommendation — Review and revoke token-backed access promptly when the browser context is no longer trusted. | ||
| NIST SP 800-63 | 3.1.3 — Session Threat Mitigation | The storage choice changes session persistence and replay exposure. |
| Recommendation — Design token sessions to expire quickly and require reauthentication after trust loss. | ||
Practitioner Guidance
What to prioritise: Treat the storage choice as part of your token threat model, not a front-end implementation detail. If the application handles high-value data or privileged actions, default to the shortest-lived workable token strategy and shorten the period during which a stolen token remains useful.
Decision rule: If the SDK must survive refresh or browser restarts, use local storage only when the browser environment is managed, script sources are tightly controlled, and token revocation or expiry is fast enough to limit replay. If those conditions are weak, accept reauthentication friction rather than durable browser persistence.
What to verify: Confirm whether the SDK stores access tokens, refresh tokens, or both, and verify how logout, expiry, and revocation behave after a browser restart. Also verify that application-side hardening, especially against script injection, is strong enough that storage choice is not carrying the whole security burden.
Practitioner takeaway: In-memory storage reduces persistence risk, but local storage is only acceptable when continuity is worth the added exposure and the browser context is genuinely controlled.
Related resources from NHI Mgmt Group
- What is the difference between cookies and local storage for web application security?
- What is the difference between token enrichment and authentication?
- What is the difference between authentication and authorization in web apps?
- What is the difference between token-based API authentication and certificate-based authentication?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
