OAuth providers

Choose which OAuth buttons appear, set the provider up in Supabase, and let users link several sign-in methods to one account.

Choose the buttons

NEXT_PUBLIC_AUTH_OAUTH_PROVIDERS is a comma-separated list of Supabase provider ids:

NEXT_PUBLIC_AUTH_OAUTH_PROVIDERS=google,github
  • Not set: only Google is shown.
  • none (or an empty value): no OAuth buttons.

apps/web/config/auth.config.ts accepts these ids: apple, azure, bitbucket, discord, facebook, figma, github, gitlab, google, kakao, keycloak, linkedin, linkedin_oidc, notion, slack, spotify, twitch, twitter, workos, zoom, fly.

Set the provider up in Supabase

The variable only controls the buttons. Each provider also needs a client id and secret in your Supabase project (Authentication, then Sign In / Providers).

The local apps/web/supabase/config.toml turns on no OAuth provider, so the default Google button fails locally until you add an [auth.external.google] block there, or set the variable to none.

Redirect URLs

Providers return to /auth/callback. The local stack allows:

  • http://localhost:3000/auth/callback and http://localhost:3000/update-password for the web app
  • shipanysaas://** for the phone app (the scheme in apps/native/app.json)

In production, add https://<your-domain>/auth/callback to your Supabase project's redirect URLs and set the Site URL to your domain. If you rename the phone app's scheme, change it in app.json, the Supabase redirect list and the dashboard together.

Sign in with Apple on the phone app needs its own setup: see docs/native/config-requirements.mdoc.

Linking several methods to one account

With NEXT_PUBLIC_AUTH_IDENTITY_LINKING=true, users can connect more sign-in methods (another OAuth provider, or email and password) to their account from account settings. Supabase must allow manual linking as well; the local stack does (enable_manual_linking = true).