Changing `fetchAccessToken` causes all Convex queries to throw unauthenticated errors

[widavies]

I'm hitting a corner case in my application that causes Convex queries to fail when the JWT access token changes.

My setup is roughly:

1. User changes their password.
2. My auth library issues a new JWT/session id. I pass this as a dependency to fetchAccessToken, so fetchAccessToken re-runs to grab this new access token, This causes ConvexAuthStateLastEffect to run client.clearAuth()
3. Convex immediately throws errors for all of my subscribed queries (they run against the clearAuth auth state)

You can see the failed queries in the sync network log:

As I understand it, this error occurs because the auth state temporarily flickers to unauthenticated (the Authenticate, tokenType: None in the sync log). When the token is cleared, Convex re-runs subscribed queries against this unauthenticated state, all of which fail).

I double checked that my new JWT is valid and non-expired. It has valid iat, aud, sub, and exp claims.

I believe this may be a bug in Convex - Convex should not re-run queries on this intermediate identity state during a fetchAccessToken change.

I can think of two solutions:

1. Convex should not re-run subscribed queries against the temporary unauthenticated state. Probably this means not sending the intermediate tokenType: None when fetchAccessToken is changed. I've confirmed that commenting out client.clearAuth in ConvexAuthStateLastEffect works.
2. Provider the developer a way to indicate that the session is changing from one logged in session to another. Convex would then 1) unsubscribe all queries 2) push the new JWT/identity 3) resubscribe all queries.

In both cases, the developer would be responsible for unsubscribing all useQuery's that would fail on the new session (because of differing permissions) prior to changing fetchAccessToken.

This might also be related to expectAuth - maybe it should always apply, not just to the initial refetch.

[widavies]

If anyone else is having a problem with this, I have a workaround:

const fetchAccessToken = useCallback=({forceRefreshToken}) => {
  // Implementation
-}, [jwt]);
+}, []);

+useEffect(() => {
+  convex.setAuth(fetchAccessToken);
+}, [jwt]);

This still causes the auth state to get sent to Convex, but it avoids fetchAccessToken from changing and causing client.clearAuth to run

[thomasballinger]

Hi @widavies, thanks for writing this out.

This is a limitation of expectAuth: true, and a reason we're not yet recommending this path and it's still an experimental option: if you intend to change the fetchAccessToken function, expectAuth is not sufficient. You need to wrap (the authed portions of the React tree of) your application in <Authenticated> so it can stop rendering all components first, then switch auth, then render the new ones.

For why expectAuth: true can't be sufficient, imagine a component with a useQuery(api.messages.list) that has child components with const messageIds = useQuery(api.message.details, {id}). If we change the auth without unmounting these components first, the child components will now be requesting ids that the new auth may not give them access to, causing errors.

That's the intention anyway! But it sounds like your JWT is for the same user, so you actually could safely switch here; all that's changing is their password. Still we want this to work for these "changing user" situations (more often it's changing "organization" in Clerk or WorkOS etc.). So your workaround seems like the right approach for background JWT change experience that you want.

Today changing the identify of the fetchAccessToken means what you expected, it causes that function to immediately be called to fetch new auth. It's not clear to me why we need to clear auth here though; pausing queries (which happens automatically on calling setAuth()) should be enough. I don't understand why we need this to clear auth here, I'll add it to the list to look into.

---

1. I agree, I don't see why this wouldn't work
2. Today that's what passing a new fetchToken is supposed to do! The interface could be clearer but each time we get a new token.

In both cases, the developer would be responsible for unsubscribing all useQuery's that would fail on the new session (because of differing permissions) prior to changing fetchAccessToken.

This might also be related to expectAuth - maybe it should always apply, not just to the initial refetch.

Ah you you already called out the issue above that makes <Authenticated> necessary, yeah if we change the contract (or make expectAuth work better) that could be the recommended approach.

---

The action item here is "consider not clearing auth if we know we're switching to another fetchToken() function" (vs logging out, when we do need to clear auth). I don't have bandwidth for this right now but it's a good idea, at least skimming the code now I don't see why we need this.

[thomasballinger]

Here's a proof of concept here that I haven't tested #83

Writing this out helped me think through that this should work for you if you used <Authenticated>, and what this does enable is a narrow use case. But if we expect developers to use expectAuth then I agree we need this change, and I agree there's no good reason to clear auth when switching between these. If we have an interactive test that shows this working with Clerk orgIds then we can do it, but hopefully with less code.

[widavies]

@thomasballinger Thanks for the fast response! You guys are in a different league with your response times.

I'll test it out, but this looks like exactly the right way to handle this for right now. The expectAuth things seems a bit more complex, and if I'm not flickering the auth state to "unauthenticated" anyway, I can't see why I would need it aside from the initial connection.

Thanks so much!