Use supabase as an OIDC provider

[alita-moore]

I want to use a separate suupabase project as my OIDC provider from a separate supabase project, how can I do this without hacky workarounds?

[NikolaySt]

This is a structural limitation of Supabase’s current design, not “missing docs”.

Supabase has a hard separation between:

1. Control plane identities (Dashboard / Org members at supabase.com)
2. Data plane identities (per-project Auth service, auth.users, sessions)
3. Project scoping + routing enforced at the API gateway (Kong)

Every Supabase “project” is effectively its own isolated deployment boundary (kong, auth, rest, postgres, storage, edge-functions, etc.). Because of that, “Project A is the OIDC provider for Project B” isn’t just enabling OIDC — it’s asking for federation between two independent data-plane stacks.

Even if Project B can verify an external JWT (stateless), you still hit two practical issues:

• Project B cannot mint/refresh native Supabase Auth sessions for identities owned by Project A (no token-exchange / shared auth plane)
• Calls still need a project context at the gateway layer (apikey / routing / policy), which pushes you into either exposing per-project anon keys client-side or introducing a server component that injects them.

How we solved it (control-plane user -> project-scoped access without duplicating users)

We built a small “platform gateway” that bridges control plane identities into each project without registering the same user in every project.

High-level idea:

• Authenticate users once against the PLATFORM (control plane / org membership)
• Replace supabase-js’ dependency on the project Auth endpoints by providing a minimal Supabase-compatible surface
• Proxy PostgREST calls and enforce RLS via transaction-scoped session context (SET LOCAL)

Concretely we implemented:

1. /auth/v1/user endpoint (Supabase-compatible)

   • Validates platform JWT
   • Returns a Supabase-shaped user object (id/aud/role/app_metadata/user_metadata)
   • Includes project_ref + org context in app_metadata

2. /auth/v1/session endpoint (Supabase-compatible)

   • Validates platform JWT
   • Returns a Supabase-shaped “session” where access_token is the platform JWT
   • (We treat the platform JWT as the bearer token supabase-js will keep using)

3. /rest/v1/* PostgREST-compatible proxy

   • Validates platform JWT + resolves target project via X-Project-Ref
   • Uses a per-project connection string server-side (cached)
   • Executes queries inside a transaction and sets session context:
     SET LOCAL app.user_id = ''
     SET LOCAL app.project_id = ''
     SET LOCAL app.organization_id = ''
   • RLS policies read current_setting('app.user_id', true) etc.
   • We restrict allowed schema/tables (e.g. chat.* only), and we parameterize filters.

This gives us:

• One “real” user identity (platform user)
• Many project backends
• No duplicated auth.users across projects
• RLS enforced per request via session context
• supabase-js works normally from the client, but points at our gateway base URL

Minimal “simple solution” for the OP (actionable)

If you want the simplest workable approach today, do this:

A) Put a gateway in front of tenant projects (Next.js API routes, Edge Functions, or any API)
B) Require a single “platform JWT” for all clients
C) Implement just these 3 endpoints:

• GET /api/platform/project/:ref/auth/v1/user
• GET /api/platform/project/:ref/auth/v1/session
• ALL /api/platform/project/:ref/rest/v1/* (proxy -> Postgres)
  D) In the proxy, run every DB call in a transaction with SET LOCAL context, and write RLS policies against current_setting().

Client usage becomes:

const supabase = createClient(
'https://YOUR_HOST/api/platform/project/',
platformJWT,
{
global: {
headers: { 'X-Project-Ref': '' }
}
}
)

Now supabase.auth.getUser(), supabase.auth.getSession(), and supabase.from(...).select(...) work,
but auth is your platform auth, and project selection is controlled server-side.

This is not “native Supabase federation”, but it is a clean, minimal pattern that works with
Supabase’s current per-project isolation model.

[alita-moore]

I only read the intro, pretty sure this is written by AI, anyway, I'm asking how to use the supabase OIDC server from one project as the OIDC provider / consume that server on another project. They're separate, but that shouldn't prevent this use case

[NikolaySt]

Fair point let me answer your exact question directly and keep it short. The formatting was AI, but the content reflects my own analysis.

You can use Project A OAuth/OIDC server as an IdP and configure Project B to accept JWTs issued by A. However, today that only gives you stateless JWT verification for Project B APIs. It does not create a native Supabase Auth session in Project B, and it does not remove the requirement to call Project B with its own project context (i.e. Project B apikey).