Switch from Google to signo: Supabase

Supabase Auth has supported custom OIDC providers since April 2026. Tested on 20 Oct 2026 against a running signo with self-hosted Supabase Auth v2.197.0, using its admin API. A new person signed up and signed in, and a person who already had an account kept it.

The examples use login.example.com for signo and example.com for your site.

Before you start

Supabase only accepts an issuer it can reach on the public internet. The issuer must be an https URL, and it must not point to localhost or to a private network address. The public signo at usesigno.co.uk meets all three, and so does a signo set up with the Docker guide on a public domain. A signo you can only reach on your own machine or office network does not.

1. Register Supabase with signo

On the public signo, sign in at https://usesigno.co.uk/account/sites and add Supabase as a site, with the redirect URI below. The page shows the issuer (https://usesigno.co.uk), a client ID and a client secret.

On your own signo, run this on its server instead:

docker compose exec signo signo clients add --name "Example" --redirect-uri https://<project-ref>.supabase.co/auth/v1/callback

It prints the issuer, a client ID and a client secret. For self-hosted Supabase, the redirect URI is https://<your Supabase domain>/auth/v1/callback. The dashboard also shows the exact callback URL when you create the provider.

2. Add signo as a custom provider

In the dashboard: Authentication → Sign In / Providers → Custom Providers → New Provider. Choose the OIDC option, which finds signo's endpoints from its issuer URL, and enter:

Or with the admin API from a server, using your secret key:

await supabase.auth.admin.customProviders.createProvider({
  provider_type: 'oidc',
  identifier: 'custom:signo',
  name: 'signo',
  client_id: process.env.SIGNO_CLIENT_ID,
  client_secret: process.env.SIGNO_CLIENT_SECRET,
  issuer: 'https://login.example.com',
  scopes: ['openid', 'email', 'profile'],
})

The test created the provider with these fields through the HTTP endpoint behind that call, POST /auth/v1/admin/custom-providers. Supabase turned PKCE on for it (pkce_enabled: true), which signo requires. The dashboard form takes the same values. A Free plan project can have up to three custom providers.

3. Change the sign-in call

-await supabase.auth.signInWithOAuth({ provider: 'google' })
+await supabase.auth.signInWithOAuth({ provider: 'custom:signo' })

The rest of your code is unchanged. In the test, the Supabase session carried the person's email, email_verified: true, their name, and custom:signo as the provider.

4. Keep your existing users

Nothing to do. Supabase links a sign-in to the existing user with the same verified email, and signo only sends verified emails. In the test, a user who already existed signed in with signo and kept the same user ID; the account then listed both its original identity and custom:signo.