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/callbackandhttp://localhost:3000/update-passwordfor the web appshipanysaas://**for the phone app (theschemeinapps/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).