Integrating a custom auth flow with Supabase client while taking advantage of RLS

[rkhatkhede]

In this discussion,
@kiwicopple said: If you wanted to still use Row Level Security, then you would need to add the user's JWT to the client library:

const headers = { Authorization: 'Bearer USER_JWT' }
const supabase = createClient( "https://REF.supabase.co",  "KEY", { headers });

As per my understanding USER_JWT is obtained through

const {session} = await supabase.auth.signUp({ email, password })
const jwt =session.access_token

But since we are not using supabase.auth how do I get/create the USER_JWT the right way? What does it look like?
Also Internally it seems for RLS I think auth.user.uid is compared to sub from jwt.
Is this integration possible? or should I give up on RLS?

[awalias]

hey @rkhatkhede !

yes you can mint your own JWTs from anywhere, you need to grab the jwt_secret from the dashboard:

in Settings > API

and then you can mint your own tokens anywhere using something like jsonwebtoken lib

var jwt = require('jsonwebtoken');
var token = jwt.sign({
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "someclaim" : "VaaVaaVoom"
}, jwtSecret);

(you can test this on https://jwt.io/ also)

and set it as a header in supabase-js in the way that you mentioned:

const headers = { Authorization: 'Bearer USER_JWT' }
const supabase = createClient( "https://REF.supabase.co",  "KEY", { headers });

additionally you can create your own RLS helper functions to pull out values from the JWT like:

-- Gets some custom claim from the request JWT
create or replace function auth.someclaim() returns uuid as $$
  select nullif(current_setting('request.jwt.claim.someclaim', true), '')::uuid;
$$ language sql stable;

then write a policy like:

create policy "my new policy"
on mytable
for select
using (
  auth.someclaim() = mytable.somecolumn
);

[darlanjunior]

To those who come across this in the future: it no longer works.
Inside SupabaseClient.ts:181 there's this:

  private _getAuthHeaders(): { [key: string]: string } {
    const headers: { [key: string]: string } = {}
    const authBearer = this.auth.session()?.access_token ?? this.supabaseKey
    headers['apikey'] = this.supabaseKey
    headers['Authorization'] = `Bearer ${authBearer}`
    return headers
  }

It overrides the Authorization header you set on createClient with the one in session().access_token.
All you need to do is call client.auth.setAuth(jwt) and everything should work as expected.
I'm not sure if it's also necessary to set { role: 'authenticated', aud: 'authenticated' } in your jwt

[dotlouis]

If you're minting your own token into a restricted environment (Vercel Edge functions, Cloudflare workers) you can't use the jsonwebtoken package. You can go with @tsndr/cloudflare-worker-jwt or jose which do not use eval.

Here's what it looks like with jose: (I needed a token with no expiry date)
More in this example

  const token = await new SignJWT({
    role: 'authenticated',
    someclaim : 'VaaVaaVoom'
  })
    .setProtectedHeader({ alg: 'HS256' })
    .setSubject(userId)
    .setAudience('authenticated')
    .setIssuedAt()
    .sign(new TextEncoder().encode(process.env.SUPABASE_JWT_SECRET))

[alexanderwe]

@awalias, @dotlouis Do I understand this correctly that some can use this approach to create like customer facing API keys which customers can use to retrieve their data by scripts, CLI's etc. ?

[ChuckJonas]

Same question as @alexanderwe. Can we create these with no expiration?