Auth token expiration pattern?

[harvitronix]

In a component, I'm fetching data from an API that requires an auth token. That looks like this:

const { data } = useSWR(['/api/ideas', user.token], fetcher)

My fetcher is a simple fetch call like so: async (url, token) => await fetch(url, { headers: { token } })

My issue arises when the token expires (every hour, I'm using Firebase auth), and I switch from another tab back to my app (revalidation on focus). SWR makes the call again, but the API returns a 401 since the token is no longer valid. If I refresh the page, the component gets a refreshed token from the auth handler and the call works again.

So I'm curious how others handle this pattern. Since the component isn't re-rendering on focus, and my fetcher function doesn't inherently have access to the auth handler, where should I be handling the 401/token refresh? 🙏

[matamatanot]

@harvitronix

Here is my fetchWithFirebaseUser pattern.
I hope this will help.

const { data } = useSWR(user ? [`/foo/${id}`, user] : null, fetchWithUser);

export const fetchWithUser = async (url: string, user: firebase.User) => {
  const token = await user.getIdToken();

  return fetch(`${baseUrl}${url}`, {
    method: "GET",
    credentials: "include",
    headers: {
      "Content-Type": "application/json; charset=utf-8",
      Authorization: `Bearer ${token}`,
    },
  }).then((res) => {
    if (res.ok) {
      return res.json();
    } else {
      throw Error;
    }
  });
};

[harvitronix]

This seems to be working well for my use case after a couple days of use. Thanks again for the help, it's greatly appreciated.

[harvitronix]

I ended up implementing this slightly differently. I was getting fetch refreshes from unrelated changes to my user object, so instead I passed the token method into the fetcher directly. Essentially this:

const { data } = useSWR(user ? [`/foo/${id}`] : null, (url) => fetchWithUser(url, user.getIdToken);

This way the user changing doesn't change the SWR key, but the fetcher can always have a valid token.

[oiojin831]

@harvitronix Isn't getIdToken a function?
Does it work if you use user.getIdToken?

[harvitronix]

Yes, getIdToken is a function.

[haarism]

I ended up implementing this slightly differently. I was getting fetch refreshes from unrelated changes to my user object, so instead I passed the token method into the fetcher directly. Essentially this:

const { data } = useSWR(user ? [`/foo/${id}`] : null, (url) => fetchWithUser(url, user.getIdToken);

This way the user changing doesn't change the SWR key, but the fetcher can always have a valid token.

This still doen't expire caches and even when new token is in effect user.getIdToken, same old cached response goes to onSucess event in SWRConfig. This is the case even when token is part of key [/api/user', token]

[messerc]

I've run into this, and the swr docs do not do this pattern justice. There's a difference between data dependencies influencing the key where the data is stored / how it is fetched, and access tokens. It doesn't really make sense to cache values based on an access token. This part of the docs:

Multiple Arguments
In some scenarios, it's useful to pass multiple arguments (can be any value or object) to the fetcher function. For example:

useSWR('/api/user', url => fetchWithToken(url, token))
This is incorrect. Because the identifier (also the index of the cache) of the data is '/api/data', so even if token changes, SWR will still have the same key and return the wrong data.

Instead, you can use an array as the key parameter, which contains multiple arguments of fetcher:

const { data: user } = useSWR(['/api/user', token], fetchWithToken)

// ...and pass it as an argument to another query
const { data: orders } = useSWR(user ? ['/api/orders', user] : null, fetchWithUser)

This tries to present an access token problem but the presented solution is also not ideal for the reasons stated in the OP. You ideally fetch a fresh / current token from within the fetch function itself, not outside of it. This is an important concept that gets lost here, might be worth adjusting.

Thanks @matamatanot - this was the path I was going down and good to see it validated.

[harvitronix]

I'm not sure if this is right for every scenario, but see my comment above. I ended up doing a bit of a hybrid of the two. Rather than passing the token as an argument, I pass the token getter method so that it doesn't impact the SWR key, but it does ensure a fresh token on subsequent fetches. (At least that's the theory.)

[matamatanot]

Hi! I posted a comment auth patterns about Plugin / middleware. #172 (comment)
Please let me know your thoughts and reactions!

[jithureddy]

The multiple arguments are very useful when APIs are secured with an authentication token which expires in specified time. But there is a problem with multiple arguments where we cannot revalidate the useSWR using the global mutate function because the key is some auto-generated one.