Clerk + Supabase third-party auth: RLS on the auth.jwt() sub claim, and the JWT template it replaced

Set up the native integration

In the Clerk Dashboard, open the Supabase integration setup and select Activate Supabase integration, which shows your Clerk domain. In the Supabase Dashboard, open Authentication, then Sign In / Providers, select Add provider, choose Clerk and paste that domain. For local development with the Supabase CLI, add the provider to supabase/config.toml; your Clerk instance still needs the Supabase integration turned on.

[auth.third_party.clerk]
enabled = true
domain = "example.clerk.accounts.dev"

Pass the Clerk session token to supabase-js

Give createClient an accessToken function that returns the Clerk session token, with no template name. On the server, call auth() from @clerk/nextjs/server; in a Client Component, read the session with useSession() from @clerk/nextjs. With accessToken set, supabase.auth cannot be used on that client, and the users stay in Clerk: the integration does not sync them into Supabase.

// Server, as in Clerk's Next.js example
import { createClient } from '@supabase/supabase-js'
import { auth } from '@clerk/nextjs/server'

export function createServerSupabaseClient() {
  return createClient(process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!, {
    async accessToken() {
      return (await auth()).getToken()
    },
  })
}

// Client Component
const { session } = useSession()
const supabase = createClient(url, publishableKey, {
  accessToken: async () => session?.getToken() ?? null,
})

RLS policies on auth.jwt()->>'sub'

Keep the Clerk user id in a text column that defaults to the sub claim, and compare against it in each policy, wrapped in select so Postgres evaluates it once per query. This is Clerk's own example:

create table tasks(
  id serial primary key,
  name text not null,
  user_id text not null default auth.jwt()->>'sub'
);
alter table "tasks" enable row level security;

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

create policy "Users must insert their own tasks"
on "public"."tasks" as permissive for insert to authenticated
with check ( ((select auth.jwt()->>'sub') = (user_id)::text) );

Why auth.uid() fails with Clerk

Supabase's third-party auth docs say auth.uid() casts sub to uuid, so it fails when a provider issues ids that are not UUIDs, and Clerk ids look like user_2abc. A policy written with auth.uid() errors or matches nothing, and the quick fix, using (true), lets every signed-in user read every row. Replace both with the sub comparison above.

Organization claims in the v2 session token

Clerk's v2 session token puts the active organization in an o claim: the id is auth.jwt()->'o'->>'id' and the role, without the org: prefix, is auth.jwt()->'o'->>'rol'. Version 1, deprecated on April 14, 2025, used the flat org_id and org_role claims. Supabase's example policy reads both:

organization_id = (select coalesce(auth.jwt()->>'org_id', auth.jwt()->'o'->>'id'))

Moving off the deprecated JWT template

The old setup pasted your Supabase JWT secret into a Clerk JWT template named supabase and called getToken({ template: 'supabase' }) for each request. Supabase still lets it work unofficially, with limited support, and calls sharing the JWT secret with a third party a problematic security practice. To move, turn on the integration, add the provider in Supabase, and replace the template call with getToken() through accessToken.

Checklist

Move a Clerk + Supabase app to the native integration

1. 01Activate the Supabase integration in the Clerk Dashboard and copy the Clerk domain.
2. 02Add Clerk under Authentication, Sign In / Providers in Supabase, and to supabase/config.toml for local development.
3. 03Replace getToken({ template: 'supabase' }) with the accessToken option and getToken() with no template.
4. 04Give each per-user table a text user id column that defaults to auth.jwt()->>'sub', and policies that compare (select auth.jwt()->>'sub') with it.
5. 05Replace every auth.uid() in your policies, and every using (true) that stood in for one.
6. 06Sign in as two different users and confirm neither can read or change the other's rows.

Related

Related guides

• SupabaseClerkSupabase Auth vs Clerk: which login system should you choose?Comparison
• ClerkClerk Production Setup Checklist for AI-Built AppsChecklist
• SupabaseWhy is my Supabase RLS policy not working?Guide
• SupabaseSupabase Auth and RLS Checklist for AI-Built AppsChecklist

Sources

Official docs behind this checklist

• Clerk, Integrate Supabase with Clerk
• Clerk, Session tokens
• Clerk changelog, Supabase third-party auth (2025-03-31)
• Supabase, Clerk third-party auth
• Supabase, Third-party auth overview
• Supabase, Custom OIDC providers
• Supabase, Third-party monthly active users
• supabase-js, accessToken option

FAQ

FAQ for builders before launch