Where to store a JWT token properly and safely in a web based application?

Question

I'm familiar with Web Storage APIs and cookies but I can't figure what is the most secure way to store an authentication token. I'm wondering if this might break any third-party libraries.

I'd like to have an exhaustive list of available methods to do so, with the pros and cons of each and the best way above all, if any.

Quass

Answer 1

Where to Store Your JWTs

With token-based authentication, you are given the choice of where to store the JWT. We strongly recommend that you store your tokens in local storage/session storage or a cookie.

Web Storage (local storage/session storage)

Commonly, the JWT is placed in the browsers local storage and this works well for most use cases.

When logging in a user with a username and password, the response body contains the access_token JWT. Then you need to handle this response in the client side code. This token can then be stored in localStorage or sessionStorage.

Click here for an example using sessionStorage

Both localStorage and sessionStorage both extend Storage. The only difference between them is the persistance of the data:

localStorage - data persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.

sessionStorage - Changes made are saved and available for the current page, as well as future visits to the site on the same window. Once the window is closed, the storage is deleted.

Web Storage Disadvantages

• Unlike cookies, local storage is sandboxed to a specific domain and its data cannot be accessed by any other domain including sub-domains.
• Web Storage is accessible through JavaScript on the same domain so any JavaScript running on your site will have access to web storage, and because of this can be vulnerable to cross-site scripting (XSS) attacks.
• The developer must ensure that the JWT is always sent over HTTPS and never HTTP.

Using Cookies

You can also use cookies to store the JWT. The exact way to set a cookie depends on the client side language you are using.

There are different options to control the lifetime of a cookie:

• Cookies can be destroyed after the browser is closed (session cookies).
• Implement a server side check (typically done for you by the web framework in use), and you could implement expiration or sliding window expiration.
• Cookies can be persistent (not destroyed after the browser is closed) with an expiration.
• Cookies can be read by both the JavaScript and the server side code or only server side if the httpOnly flag is set.

Cookie Disadvantages

• The max size of a cookie is only 4kb so that may be problematic if you have many claims attached to the token.
• Cookies can be vulnerable to cross-site request forgery (CSRF or XSRF) attacks. This type of attack occurs when a malicious web site causes a user’s web browser to perform an unwanted action on a trusted site where the user is currently authenticated. This is an exploit of how the browser handles cookies. Using a web app framework’s CSRF protection makes cookies a secure option for storing a JWT. CSRF can also be partially prevented by checking the HTTP Referer and Origin header.
• Can be difficult to implement if the application requires cross-domain access. Cookies have additional properties (Domain/Path) that can be modified to allow you to specify where the cookie is allowed to be sent.

Original article: https://auth0.com/docs/security/store-tokens#how-to-implement

Razorbill

Hi I like your Answer. One more question though refering to this: "Unlike cookies, local storage is sandboxed to a specific domain and its data cannot be accessed by any other domain including sub-domains" Could you provide an example please? What does that mean in practice? – Ustulation

Answer 2

1. JWTs should never be stored in your localStorage
2. In fact, they shouldn't even be stored in your cookies, unless you are able to implement very strict CSRF protection

Checkout this for motivation

• JWT as an id_token is like your user credentials
• JWT as an access_token is like your session token

The most secure option is in-memory. Checkout this for a deep dive

Frymire

The question asked where to store JWTs, but your answer only answers where not to store JWTs and provides some links. Answers should mostly be self contained, so if the links have the answer it would be good to bring that information into your answer. – Emerson

@Emerson the answer is in the last line: "The most secure option is in-memory". – Gruver

In-memory storage seems to be doable only in single page applications as far as I understand. – Lizbeth

@Lizbeth it won't as the 2nd part of the article proposed that the website should store a refresh token on the browser. Whenever a user navigate to another page or reopen the website, javascript will use this refresh token to exchange for a fresh authentication token. – Mitchellmitchem

Answer 3

If @dmitry-s solutions still didn't work for you, consider storing your access token in the Web Worker as this article suggests.

Web Worker has it's own thread and does not provide malicious third-party or XSS scripts a chance of obtaining the token (as localStorage and sessionStorage do). But take in mind, that you'll have to design the way your frontend code communicates with the Web Worker to safely make API requests.

It is widely spread in modern browsers, but you may check if it works out well for your users here.

Nullification