What is a correct way to refresh access tokens

[adanielyan]

I am new to remix, and so far I love this framework.

However I've been struggling with one issue for a few days and I am now stuck. I have Directus as my headless CMS and authentication service for my users. The way auth works is you get an access token and a refresh token. The refresh token is used to get a new access token when the old one expires. The problem is that I don't know where to put my access token refresh code.

If I put it in the loader of root.tsx it works fine for the initial load, but then if I start navigating from one route to another and a token refresh is needed at some point, the code in root.tsx doesn't fire. So I end up with failed requests in my loaders. If I place that code in every route that requires authentication, then I have code racing on initial load when there are nested routes that have the token refresh code in their loaders. I cannot have the token refresh only in the leaf routes, as I have parent routes that also need the user object, for example to render a user menu in the page navigation.

I should say that I user Remix Server and would prefer not switching to Express unless I absolutely have to.

I don't know how to proceed and this issue is just driving me crazy. Have anyone else had to deal with this problem? I would appreciate any advice.

[kiliman]

Here's some pseudocode that should help. The "trick" is to verify the token, and if it's expired, get a new token and redirect back to the same page. You should now have the correct token.

export const loader = async ({request}) => {
  const token = await verifyToken(request)
  // the token will be valid here because it either hasn't expired
  // or we refreshed the token and threw a redirect with new token

  //... do what you need to do with the token
}
 
async function verifyToken(request: Request) {
  let token = await getToken(request)
  if (isExpired(token)) {
    token = await refreshToken(request)
    // token is now valid, so redirect back to same page
    // and Remix will resend the request with the new token
    // we throw here so we don't have to check return in loader
    throw redirect(request.url, { headers: { 'set-coookie': tokenCookie }})
  }
  // token should be valid here, so return it
  return token
}

[sergiodxa]

In some cases loaders can be called individually, even with Single Fetch, so while in most cases it may be like a middleware, but it's not safe to use as one

[adanielyan]

That's interesting! Can you please elaborate? In what cases loaders can be called individually?

[sergiodxa]

Every route with shouldRevalidate or clientLoader will be fetched individually, even if the shouldRevalidate returns true or if clientLoader calls the serverLoader immediately.

So If you have app/root and app/routes/_index and your index route has both a loader and clientLoader, every client-side navigation will cause two HTTP requests, so the app/root won't work as a middleware for the index route.

Same thing if you have a shouldRevalidate in app/root, now that one will cause a separate request, so even if all of your other routes are fetched in the same request, the app/root won't, and many people use shouldRevalidate in app/root to prevent it from running in other scenarios.

[adanielyan]

Thanks for explaining!

[gustavopch]

Just want to point out that middleware support is right around the corner btw.

[adanielyan]

Thank you for your help, @kiliman!

Assuming I have nested routes and in the loaders of each route I need to make an authenticated request to my API (and therefore a valid token), should I call the verifyToken() function in each of them or only in the root?

UPDATE: If I place this only in root's loader than the verifyToken gets called only on initial page load, but not when navigating from page to page. If I place it in loaders of other routes then this function gets called multiple times on initial route which eventually leads race condition and multiple token refreshes. That's exactly what my issue is.

[barbinbrad]

Doesn't the beforeLoader just kick the can up the road? Isn't the problem still that there are multiple beforeLoader calls, but each of them would invalidate the other?

What if you stored the refresh token in an HTTP-only cookie, but gave the client access to the access token, so that it could check whether it was expired in a setInterval function -- and then if it was close to expiring, you could hit a remix resource route that does the refreshing.

The problem is similar on the client-side if you have multiple tabs open running the same check. But here you use localStorage mutex to prevent all the tabs from making the same request (assuming the access token that was being checked was being shared in localStorage).

[adanielyan]

I tried calling a fetcher in useEffect in my root.tsx when the transition becomes "submitting", but the root component doesn't get re-rendered when navigating from one child route to another. Which means that I will have to call a fetcher to refresh endpoint on a client sides of my leaf routes, which is not much different from calling it in loaders.

Calling a fetcher in setInterval sounds way too hacky to me.

[barbinbrad]

Totally understanding your perspective. I guess the idea I was trying to advocate for is that you wouldn't need to check on each request IF you made sure you checked before any request is made. Here's an example where you'd run some code like this in your root if the user was authenticated:

React.useEffect(() => {
   sessionService.ensureSession();
}, []);

And here's what ensureSession() would look like: https://github.com/gravitational/webapps/blob/4da005d774cff0820b50439541a3d6ee1f89d0b3/packages/teleport/src/services/websession/websession.ts

[adanielyan]

Thank you for sharing a code example. It's an interesting approach. While it's not really a remix way, it may be the only way for now.

[barbinbrad]

Definitely! Parallelized requests are great for performance, but make shared auth state trickier. I'm looking forward to see where this discussion goes over time.