v2.0.0 regression: Custom JWT (particularly in realtime Channels)

[LuisAngelVzz]

Bug report

Description

Using a custom JWT was a feature in v1 :
https://supabase.com/docs/reference/javascript/auth-setauth

Per comment:
supabase/auth-js#340 (comment)
what we did was establish the custom header and it works for creating the client.

However, it's not working with realtime channels. Upon inspection, the problem is that the internal initialization isn't setting up RealtimeClient's setAuth method:
https://github.com/supabase/realtime#realtime-rls
which in turn causes the web socket to not send the JWT on the messages and heartbeats..

The result is that channels fail the RLS.

A second problem is with setting up a new valid JWT when the previous one expired: there's no way to do it. Not in the supabase client and much less in the realtime client.

To Reproduce

1. Create a database with a restrictive policy based on a custom JWT
2. Create a JWT with a 1 minute expiration time
3. Create a client using the method explained in
   feat: remove deprecated session methods auth-js#340 (comment)
   4.a. Let 2 minutes go by and try to make any call to supabase using supabaseClient. Access is denied because the JWT has expired. Try to update the JWT -> there's no way to do it. Would have to create a new client but that defeats the whole thing.
   4.b. Create a channel subscription -> 'fails' by not providing access to rows to which the user has access acording to the policy)

Upon inspection of the websocket, as it was expected, the messages and heartbeats don't include the custom JWT.. Why whould they? We've only set the header /directly/ and that's it..

Workaround

What we've done is changing from protected to public the supabase client's class elements:
"headers" in SupabaseClient
"realtime" in GoTrueClient
and we're calling
a) supabaseClient.realtime.setAuth(JWT)
b) supabase.auth.headers.Authorization = Bearer ${JWT};
with the customToken..

That keeps everything working..

Tried forking and creating an updateJWT method, but realized we're not very familiar with the modularization philosophy of the project and was most likely being both overkill about it. Also, were falling short because an alternate method is quite likely required for the initialization, since using the headers option in the createClient doesn't impact the realtime client.

[magicseth]

What I was hoping for was a SignInWithToken(...) api
that would take the JWT, create a session, and call the authstatechanged callbacks.

As is it feels daunting reaching in to protected fields in multiple files to achieve this.

[jmedellinc]

Any news on this? It's a regression.. Any way to get the devs attention?

[soedirgo]

cc @kangmingtay @w3b6x9

[ioucyf]

I'm looking for something like this. It'll solve so many problems I'm having right now.

[w3b6x9]

This was actually due to an issue where the Realtime client would always default to using the anon token. I released a change where Realtime client will use the global headers Authorization bearer token if present: https://github.com/supabase/supabase-js/releases/tag/v2.7.0

[w3b6x9]

I do want to mention that if your custom token is short-lived and you're refreshing it yourself you'll still have to call Realtime's setAuth in order to send the refreshed token to Realtime's servers.

[jmedellinc]

I do want to mention that if your custom token is short-lived and you're refreshing it yourself you'll still have to call Realtime's setAuth in order to send the refreshed token to Realtime's servers.

Ha..! Thanks..

I wonder if the issue of a customJWT refresh method is on the todo's ?
Not urgent.. My workaround works without issues..
(There may be something I may be missing, though..)

It's all documented on supabase/auth-js#701 along with patches to unprotect the applicable class properties:

this.supabase.headers.Authorization = Bearer ${supabaseToken};
this.supabase.auth.headers.Authorization = Bearer ${supabaseToken};
this.supabase.rest.headers.Authorization = Bearer ${supabaseToken};

which have to be updated in addition to calling setAuth again when the JWT expires..

[w3b6x9]

This was actually due to an issue where the Realtime client would always default to using the anon token. I released a change where Realtime client will use the global headers Authorization bearer token if present: https://github.com/supabase/supabase-js/releases/tag/v2.7.0

After taking a closer look the issue is on the API gateway. It only accepts Supabase signed tokens (i.e. anon, service_role).

I just added a section to Realtime docs on how to pass in custom tokens: https://supabase.com/docs/guides/realtime/postgres-changes#custom-tokens.

[yamen]

@w3b6x9 We've just been testing this and want to highlight that the docs are slightly off. They say to pass the Supabase key into headers and the custom JWT into params, whereas it's actually the other way around.

What worked for us is:

const { createClient } = require('@supabase/supabase-js')

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY, {
  realtime: {
    headers: {
      apikey: 'custom-supabase-signed-jwt-token',
    },
    params: {
      apikey: 'supabase-anon-key',
    },
  },
})

Whereas the docs say:

const { createClient } = require('@supabase/supabase-js')

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY, {
  realtime: {
    headers: {
      apikey: 'supabase-signed-token',
    },
    params: {
      apikey: 'your-custom-token',
    },
  },
})

Note that the description of the Supabase anon key in the docs is also confusing:

"The apikey in headers must be either the anon or service_role token that Supabase signed"

Other than this needing to be the apikey in params not headers, it should probably also say "that Supabase provides" rather than "that Supabase signed". This caused a mini goose chase when debugging.