Store Tokens

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.

Native/mobile apps

Single-page apps

Securing single page apps (SPAs) comes with its own set of concerns. You'll need to ensure that tokens and other sensitive data are not vulnerable to cross-site scripting and can't be read by malicious JavaScript.

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:

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.

Using cookies

Under certain circumstances, you can use cookies to authenticate a single-page application:

  • 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.

Keep reading