What are we actually storing?

After a successful OAuth 2.0 login, an application typically ends up holding one or more of the following: an access token (short-lived, used to call APIs), a refresh token (longer-lived, used to obtain new access tokens without re-login), and sometimes an ID Token (used briefly to establish identity). Each of these is, functionally, a bearer credential — meaning whoever physically possesses it can use it, exactly like cash. Unlike a password, most tokens can’t be “changed” by the user if leaked; they simply have to expire or be explicitly revoked.

Who are we protecting tokens from?

Token storage decisions are really about defending against a specific set of realistic attackers: malicious scripts running on a compromised web page (Cross-Site Scripting, or XSS), other applications on a shared mobile device, malware on a user’s computer, and network attackers if transport security is weak. Different storage locations resist different subsets of these threats — there is no single option that defends against everything perfectly.

The main storage locations in play

• Browser Local Storage / Session Storage: A simple, JavaScript-accessible key-value store built into every modern browser, tied to a specific website’s origin.
• HTTP-only Cookies: Small pieces of data automatically sent by the browser with every request to a site, but explicitly marked as unreadable by JavaScript.
• In-Memory (JavaScript variables): Data held only in a running application’s memory, disappearing the moment the page or app is closed.
• Secure Device Storage (Mobile): Operating-system-provided secure storage — the iOS Keychain or Android Keystore — designed specifically to protect sensitive credentials on a device.
• Server-Side Session Storage: Keeping the actual token entirely on a backend server, giving the browser only an opaque session identifier instead.

Which architecture typically uses which storage

graph TD
    APP["Application Type"] --> WEB["Server-Rendered Web App"]
    APP --> SPA["Single-Page Application"]
    APP --> MOBILE["Native Mobile App"]
    WEB --> COOKIE["HTTP-only Secure Cookie + Server Session"]
    SPA --> BFF["Backend-for-Frontend Pattern"]
    BFF --> COOKIE2["HTTP-only Cookie to Browser"]
    MOBILE --> KEYCHAIN["OS Secure Storage (Keychain / Keystore)"]
    

How browser local/session storage works — and why it’s risky

Local storage and session storage are simple JavaScript APIs, directly readable and writable by any script running on the page. This includes your own application’s legitimate code — but it also includes any malicious script that manages to sneak onto the page through a Cross-Site Scripting vulnerability, whether from a compromised third-party library, an unsanitized user input field, or a malicious browser extension. Once a script can run on the page at all, it can simply read a token straight out of local storage.

How HTTP-only cookies work

An HTTP-only cookie is set with a special flag that tells the browser: “never expose this value to JavaScript, under any circumstances.” The browser still automatically attaches the cookie to outgoing requests to the matching domain, but page scripts — including malicious ones — simply cannot read its contents directly. This single flag closes off an entire category of attack, though cookies introduce their own separate risk: Cross-Site Request Forgery (CSRF), where a malicious site tricks a browser into sending an authenticated request unintentionally. This is why HTTP-only cookies are almost always paired with additional protections like the SameSite attribute and CSRF tokens.

How secure mobile storage works

The iOS Keychain and Android Keystore are operating-system-level, encrypted storage areas specifically designed for sensitive credentials. Access is tied to the specific application that stored the data, and the operating system enforces this isolation at a much deeper level than anything a web browser can offer, often backed by dedicated hardware security modules on the device.

1. Receipt: The application receives tokens from the Authorization Server after a successful login.
2. Placement: The application decides where to store each token, based on its architecture (server session, HTTP-only cookie, secure device storage, or in-memory).
3. Active use: The access token is retrieved from storage and attached to outgoing API requests until it expires.
4. Silent renewal: Shortly before or after expiration, the refresh token (stored even more carefully, since it’s longer-lived) is used to obtain a fresh access token.
5. Logout / cleanup: On logout, all stored tokens should be actively cleared, not just left to expire naturally.
6. Long-term expiry: Refresh tokens themselves eventually expire or get revoked, requiring the user to log in again from scratch.

Notice that the refresh token, precisely because it lives the longest and can mint new access tokens indefinitely, deserves the single strongest storage protection in the entire system — it is often the actual prize an attacker is after, not the short-lived access token itself.

The core attack: Cross-Site Scripting (XSS) token theft

If an attacker manages to inject even a small piece of malicious JavaScript into a page — through an unsanitized comment field, a compromised third-party analytics script, or a vulnerable dependency — that script can read anything sitting in local storage or session storage and silently send it to an attacker-controlled server. This single technique has been responsible for real, large-scale account takeovers across the industry, precisely because so many applications historically stored tokens in JavaScript-accessible locations for convenience.

Cross-Site Request Forgery (CSRF) and cookie defenses

Because browsers automatically attach cookies to matching-domain requests, a malicious website could try to trigger unwanted authenticated actions on your site just by getting a logged-in user to visit it. Modern defenses include the SameSite cookie attribute (restricting when cookies are sent cross-site) and dedicated anti-CSRF tokens included in state-changing requests.

Device-level risks for mobile and desktop apps

• Jailbroken or rooted devices: Reduce the effectiveness of OS-level secure storage protections, since the device’s own security boundaries have been deliberately weakened.
• Backup and sync leakage: Some naive implementations accidentally include tokens in unencrypted app backups, exposing them outside the device entirely.
• Shared or multi-user devices: Increase risk if tokens aren’t properly cleared on logout or app removal.

• Token usage from unexpected locations: A refresh token suddenly being used from a new country or device can indicate it was stolen and is being replayed elsewhere.
• Concurrent session counts per user: Sudden, unexplained spikes may indicate a leaked token being reused by an attacker alongside the legitimate user.
• Content Security Policy (CSP) violation reports: These reveal blocked script injection attempts before they succeed, giving early warning of potential XSS attempts against your token storage.
• Refresh token rotation failures: If a refresh token is used twice unexpectedly (see rotation, below), that’s a strong signal of token theft in progress.

Recommended patterns

• Backend-for-Frontend (BFF): Keep all tokens entirely on a backend server, giving the browser only a secure, HTTP-only session cookie — widely considered the strongest pattern for web applications today.
• Refresh token rotation: Issue a brand-new refresh token every time one is used, immediately invalidating the previous one, so a stolen-but-unused refresh token becomes worthless the next time the legitimate user refreshes.
• OS-native secure storage for mobile: Always prefer the Keychain or Keystore over plain files or shared preferences for anything token-related.
• Short access token lifetimes paired with careful refresh token protection: Minimizes the window of usefulness for a stolen access token while concentrating protective effort on the more valuable refresh token.

Best practices

• Prefer HTTP-only, Secure, SameSite-configured cookies for web applications wherever possible.
• Use OS-provided secure storage (Keychain, Keystore) for every native mobile and desktop application.
• Implement refresh token rotation with reuse detection to catch theft quickly.
• Keep access token lifetimes short, and clear all stored tokens explicitly on logout, not just letting them sit until expiry.
• Apply a strong Content Security Policy to reduce the chance of a successful script injection in the first place.

Common mistakes teams actually make

It significantly increases risk in the presence of any Cross-Site Scripting vulnerability, so it’s generally discouraged, especially for refresh tokens. HTTP-only cookies or a Backend-for-Frontend pattern are safer defaults for web applications.

The refresh token, because it’s longer-lived and can be used repeatedly to mint fresh access tokens, making it far more valuable to an attacker than any single short-lived access token.

No — they effectively block JavaScript-based theft, but they introduce a separate risk, Cross-Site Request Forgery, which needs its own defenses like the SameSite attribute and anti-CSRF tokens.

It ensures a stolen-but-not-yet-used refresh token becomes useless the moment the legitimate user refreshes normally, and it gives systems a reliable signal — reuse of an old token — to detect theft in progress.

No — it significantly raises the difficulty bar compared to plain files, but device-level compromises like jailbreaking or rooting can still weaken its protections, so it should be one layer among several, not a complete solution on its own.