>...best way to store that refresh token in a ReactJS frontend

You never store refresh tokens in a frontend. You can store access tokens (short-lived) in the frontend but you should never store refresh-tokens.

I use Auth0 for my React frontend. The Auth0 folks themselves say you shouldn't use refresh tokens for single page apps, you can't trust the client-side.

Instead of using refresh tokens, they have a "silent authentication" mechanism[1]. The idea is: sometime before the user's initial token expires, your app goes through the silent-auth process in an invisible iframe. Assuming the user's authentication credentials are still valid, the invisible iframe will eventually use the browsers postMessage() functionality to deliver a new token to the main app's frame, your app then quietly starts using this new token that has a new cryptoperiod.

The silent-auth mechanism doesn't use any different inputs than a normal Auth0 SSO login. Your app is constantly re-authenticating until the user is not allowed to login any more. This allows you to set short expiration times with no interruption of the user at all.

[1] - https://auth0.com/docs/api-auth/tutorials/silent-authenticat...

JWT and Refresh tokens dont address session issues; so the answer to your question is to introduce strong session management tools.

(Id argue that JWT is the wrong tool to use in a react front end - store that in the orchestration and implement some strong session management betweem FE and orch through an access gateway)

You should not store any token in the frontend. Instead, have a server doing that and use a classic secure cookie session. The session is bound to the token / refresh token and can then do the token management.

Alternatively, don't use access token / refresh token but an ID token. The refresh of the token will be done via the ID token and the user's session (cookie) to the OAuth provider.

JWTs are designed to be stored in the client that needs to be granted authorization to resources. Nothing wrong with storing tokens in the frontend.

Agree this stuck out to me - I think a lot of confusion stems from how to handle refresh tokens - the oauth spec I feel is responsible by the confusion of how it calls apps “clients” and how flimsy it is about implementation (should/shall/must). If you are keeping refresh token locally on the user agent, you really urgently need to provide the user session management tools to revoke those things, and you need to be doing more advanced threat/abuse detection of their usage.

Most people should probably follow the pathways laid out by IdentityServer4 and oidc-client, even if not not using .NET Core (you could absolutely deploy it standalone). Lots of sane defaults, even for refresh tokens and revocations and other difficult specs to understand. It’s well maintained and well thought out.

In the article, they mention the refresh token needs to be revokable which I assume means that it is stored in a table in a database or other data store. When the user logs out, the refresh token is removed from the table (i.e. it is revoked).

The JWT server would check to see that the refresh token probably stored in the browser with a cookie or localStorage is valid before sending the new JWT.