Custom JWT: loop-refetches token, potential wrong dependency in useEffect

[antoineol]

Hi team,

[updated issue]

I am struggling to find or build a working example of custom JWT auth with ConvexProviderWithAuth + providing a custom useAuth.

My latest attempt to make it work fails with an infinite loop of refetching the JWT, likely a race condition / stale cache or something similar.

Minimal repro: https://github.com/antoineol/convex-jwt/tree/loop-refetch

git clone https://github.com/antoineol/convex-jwt.git
cd convex-jwt
git checkout loop-refetch
bun install
bun dev

Behavior you get: open localhost:3000 and check the network tab + server logs: it continuously refetches the token. The sync websocket also loops.

But it works well with the lower-level convex.setAuth(fetchToken): https://github.com/antoineol/convex-jwt/tree/working-custom-jwt-with-setauth

Thanks a lot for your help! 🙏

---

More context: I'm trying to add a nextjs + convex app next to our product existing app (Rails + devise + postgres) with live sync, to progressively migrate some pages while preserving a nice user navigation experience. It works great, except the auth.

---

[original issue]

I am trying to make the custom JWT auth work, but the auth state remains desperately unauthenticated, despite following strictly the doc steps. There is no error, nothing else, so I suspect a step is missing, but I can't find which one.

Minimal repro: https://github.com/antoineol/convex-jwt

git clone https://github.com/antoineol/convex-jwt.git
cd convex-jwt
bun install
bun dev

FYI, steps followed to build it:

• nextjs quickstart: https://docs.convex.dev/quickstart/nextjs
• Add a minimal JWT generation + JWKS URL & data URL with jose library
• custom JWT doc steps: https://docs.convex.dev/auth/advanced/custom-jwt
• Custom OIDC > Client-side integration steps to add the hooks
• A small piece of UI to show the JWT hook + the convex hook

PS: .env.local is versioned on purpose with RSA public/private key for the demo, so that all pieces are there to reproduce.

I have the feeling the issue is related to the useProviderXAuth (or useAuthFromProviderX) that is required to have a specific behavior (not documented here), like prefetching the token without waiting for an explicit call to fetchAccessToken / getToken. But maybe not with an initial value either? I'm still trying to clarify it.

[antoineol]

Latest state: it works well with the lower-level convex.setAuth(fetchToken);: https://github.com/antoineol/convex-jwt/tree/working-custom-jwt-with-setauth

It's still failing in my latest attempt to use ConvexProviderWithAuth and its useAuth prop: https://github.com/antoineol/convex-jwt/tree/loop-refetch

Behavior: continuously refetching the token.

I guess something is wrong with this wrapper, but I couldn't find what exactly. In verbose mode, I found a kind of "stale" version, that might be triggering a double-fetch, one of them giving an "unauthenticated state" for whatever reason, and forcing a refetch.

At first sight, the setAuth + expectAuth: true in the config is good enough for me. But I'd love to have your feedback on how the ConvexProviderWithAuth is supposed to be used. 😃

I guess there is at least an update to do on the doc to clarify it, and maybe a behavior to fix. This stale state + loop is very hard to debug as a lib consumer.

[DaveVaval]

I have an issue similar to yours: get-convex/better-auth#168

Following the documentation to setup BetterAuth with convex, I now get a BetterAuth session object when I log in, but the useConvexAuth hook still returns isAuthenticated: false. I was now debating on integrating my own provider with JWT, but it doesn't seem like an easier solution by your issue😅

[ezra-en]

I mentioned this in get-convex/better-auth#168, see if you can grab the JWT string by opening up your DevTools, checking the sync WebSocket stream, grabbing the value when you do find the JWT authentication attempt and decode it to check if the issuer value is the same as your baseURL. Don't share it, just place it as input in this decoder (https://gchq.github.io/CyberChef/#recipe=Split('.','%5C%5Cn')From_Base64('A-Za-z0-9%2B/%3D',false,false)) and you should be able to see the "iss": value and verify whether or not your client is requesting a bad JWT with the wrong baseURL.

[ezra-en]

In my experience, your CONVEX_SITE_URL and whatever JWT issuer you have might not actually be the same, or your client provider is having difficulty contacting your auth server in the first place.

[antoineol]

👋 @ezra-en .Thanks for answering. Are you answering to Dave or me?

For this issue, iss and other settings have been reviewed multiple times. It works with lower-level convex.setAuth, but doesn't work with higher-level ConvexProviderWithAuth. I believe it's a front issue. The minimal repro above shows this.

I edited the issue initial description to reflect the latest state of my tests.

[antoineol]

Update: on discord, a community member, Klaus, found the probable source of the bug in ConvexAuthState.ts (convex client):

https://discord.com/channels/1019350475847499849/1443243345609621594

In short, authProviderLoading presence in the 2 useEffect's dependency arrays seems wrong. Once removed, he noticed the infinite fetch loop disappears. It might have been added because of edge cases, but he couldn't figure out which ones. (Maybe related to one of the supported auth providers?)

This might require a fix in the convex-js lib.

Thanks for your help. 🙏