Why do we need logic to refresh the auth token if we set autoRefreshToken to true?

[vedantroy]

Hi! I was wondering what is the purpose of the logic that refreshes the auth token if we set autoRefreshToken to true?

My guess is that it's still useful for the scenario where an API request is sent past the expiry date (e.g an API request has not been made in a while so the access token expired before there was a chance to refresh it).

But just want to confirm.

Different Question

Oh, another question! I notice in the OAuth example, in the client you set autoRefreshToken and persistSession to false, but in the server you set those same options to true (or you leave them unset, and the default is true I think). Is there a reason for this?

remix-auth-supabase/examples/oauth/app/supabase.client.ts

Line 35 in c5d78fb

{ autoRefreshToken: false, persistSession: false },

[rphlmr]

Hi,

Hi! I was wondering what is the purpose of the logic that refreshes the auth token if we set autoRefreshToken to true?

Supabase is designed to be used by developers who doesn't want / can't have a backend for their front end.
It provides an all-in-one solution, from authentication to data storage (and now, edge functions <=> serverless api)
So, Supabase js sdk handles its own authentication logic (including refresh), client side.

Remix.run purpose is to have a full stack solution and provides some utilities like "sessionCookie" to store a user session on a secure cookie (on a secure browser place), unreadable by client side javascript
This session cookie is automatically added on requests send from client side code to your action/loader by your browser (in request headers).
Then, your backend code can access user session and make its logic (challenge the access token, deny access if expires, etc).
It's backend responsability to assert user identity, when needed, on loader/action.
Remix-Auth-Supabase provides some utilities to make this, using supabase js sdk admin features.
When authentication is success, this lib store user session in a session cookie

With this long intro in mind (:D), we now understand that everything is done server side (including refreshing user session).

But their is one exception : third party auth providers (github, magic link, etc) implementing OAuth.
These providers need to authenticate user outside of your app and require a call back url to send the authentication result on your app (they forward access token, refresh token, etc on url params).
This url has what we call a "fragment" (starting with "#") after witch we have access token, refresh token, etc.
This is part of OAuth security and browsers can't forward this part to backend.

So, it's not possible to handle that directly by a server side code and rather than making our own client side logic to parse url fragment, we rely on a client side supabase instance (it has functions to do that).
If we don't set autoRefreshToken and persistSession to false, client side supabase will store a user session.
In the end we will have 2 user sessions : one handled by our backend and one living client side.
At first it seems ok, but when refresh time comes, if client side supabase refreshes token before our server, next time our server will try to refresh its session cookie it will fail and user will be logout.
This happen because we have 2 user sessions with 2 refresh token. When a refresh token is used, others are invalidated.

Oh, another question! I notice in the OAuth example, in the client you set autoRefreshToken and persistSession to false, but in the server you set those same options to true (or you leave them unset, and the default is true I think). Is there a reason for this?

Server side doesn't need that because theses options relies on browser api (storage, event listener).
I guess supabase (which can be used client side and/or server side) knows where is it and deactivates these features.

That's the hard part on full stack code base with thing used client side and/or server side at the same time. It's like a giant puzzle :p

[cusxio]

Thank you for this very detailed response.