How and where to securely store tokens used in token-based authentication depends on the type of app you are using.
Regular web apps
ID Tokens, Access Tokens, and (optional) Refresh Tokens should be handled server-side in typical web applications. The application server use the tokens to call APIs on behalf of the user.
- Authorization Code Flow with Proof Key for Code Exchange (PKCE)
- Native/Mobile App Quickstarts
- Auth0.Android Saving and Renewing Tokens
- Auth0.swift Saving and Renewing Tokens
We recommend using the Auth0 Single Page App SDK. The Auth0 SPA SDK handles token storage, session management, and other details for you.
Don't store tokens in local storage
Browser local storage (or session storage) is not a secure place to store sensitive information. Any data stored there:
- May be vulnerable to cross-site scripting.
If an attacker steals a token, they can gain access to and make requests to your API. Treat tokens like credit card numbers or passwords: don’t store them in local storage.
- if your SPA is served to the client using your own backend
- if your SPA has the same domain as your backend
- if your SPA makes API calls that require authentication to your backend
For an overview of this approach and an example implementation, see Single-Page App Authentication Using Cookies.
If a backend is present
If your single-page app has a backend server at all, then tokens should be handled server-side using the Authorization Code Flow, Authorization Code Flow with Proof Key for Code Exchange (PKCE), or Hybrid Flow.
If no backend is present
If you have a single-page app (SPA) with no corresponding backend server, your SPA should request new tokens on login and store them in memory without any persistence. To make API calls, your SPA would then use the in-memory copy of the token.