The Ultimate Guide to handling JWTs on frontend clients (GraphQL)
— Read on blog.hasura.io/best-practices-of-using-jwt-with-graphql/

So far, this is the best article I have read that explains and answers questions on JWT (both server and client.)

That’s why it’s also really important not to store JWT on the client, say via cookies or localstorage. Doing so you make your app vulnerable to CSRF & XSS attacks, by malicious forms or scripts to use or steal your token lying around in cookies or localstorage.

So memory only? For cookies, with HttpOnly and Secure, there should be no concern about XSS or man-in-the-middle. Yes, chance of CSRF is still there. So you need anti-forgery. For example, keeping an anti-forgery token in localstorage (since value in localstorage won’t be sent automatically with each request.)

So it really depends on the balance of security vs. cost to keep it absolutely secure.

A very good point has been made in this SO thread.

This is a painful discussion on the Internet. Our short (and opinionated answer) is that backend developers like using JWTs because a) microservices b) not needing a centralized token database.

Indeed yes, the two most important benefits.

This token is issued as part of authentication process along with the JWT. The auth server should saves this refresh token and associates it to a particular user in its own database, so that it can handle the renewing JWT logic.

The refresh token is sent by the auth server to the client as an HttpOnly cookie and is automatically sent by the browser in a /refresh_token API call.

Persisting JWT token in localstorage (prone to XSS) < Persisting JWT token in an HttpOnly cookie (prone to CSRF, a little bit better for XSS) < Persisting refresh token in an HttpOnly cookie (safe from CSRF, a little bit better for XSS).