SupabaseS
Supabase•5mo ago
Navin

Migrating to using Clerk as a third party auth provider

My question is:

Is request.jwt.claims the same as auth once the third-party integration with Clerk is setup?

---

For more context ...

In the olden days, the way we integrated Clerk with Supabase was by following this https://supabase.com/partners/integrations/clerk

In particular, we defined a function as follows
create or replace function requesting_user_id()
returns uuid
language sql stable
as $$
  select uuid_generate_v5('<redacted>'::uuid, current_setting('request.jwt.claims', true)::json->>'sub');
$$;


And then used that function to set an internal UUID based user_id and define RLS policies.

Now we can set up Clerk as a third party provider for Supabase and we are advised to write policies directly referencing the auth object like so:

create policy "User can view their own tasks"
on "public"."tasks"
for select
to authenticated
using (
((select auth.jwt()->>'sub') = (user_id)::text)
);


My question is:

Is request.jwt.claims the same as auth once the third-party integration with Clerk is setup?

So, can I just redefine my requesting_user_id function to

create or replace function requesting_user_id()
returns uuid
language sql stable
as $$
  select uuid_generate_v5('<redacted>'::uuid, auth.jwt()->>'sub');
$$;

and will that just work or will it break all my existing user_id values? Thought I would ask if this is a known thing before I spend the time and energy on testing this.

Thank you.

PS: I think that this thread is relevant https://discord.com/channels/839993398554656828/1381612372350861433
Supabase
Clerk | Works With Supabase
Authentication for Next.js, React, and the Modern Web.
Was this page helpful?