Supabase (Hosted) — Auth & OAuth¶

Configure the hosted Supabase project that backs App-name in production and test: dashboard settings, Google and Microsoft OAuth, TOTP MFA, redirect URLs, and the environment variables your app consumes. For the local Docker-based stack used during development, see Supabase (Local). For how sign-in actually flows through the app, see Auth Flow.

Two projects, two environments

Run one hosted Supabase project per environment — one for production (<your-domain>) and one for test (test.<your-domain>). Each has its own URL, keys, and OAuth callback. Repeat every step below for both projects.

Prerequisites¶

Requirement	Where to get it
Supabase project (per environment)	https://supabase.com/dashboard
Google Cloud account	https://console.cloud.google.com
Azure / Microsoft account	https://portal.azure.com
DNS access (Cloudflare)	https://dash.cloudflare.com

Part 1 — Supabase dashboard configuration¶

1.1 Get project URL and API keys¶

In the dashboard, open Settings → API and use the Publishable and secret API keys tab (the newer key model). Record these three values:

Setting	Example	Maps to	Use
Project URL	`https://xxxxx.supabase.co`	`VITE_SUPABASE_URL`	Frontend and backend
Publishable key (anon)	`sb_publishable_...`	`VITE_SUPABASE_ANON_KEY`	Guest auth, obeys RLS
Secret key (service_role)	`sb_secret_...`	`SUPABASE_SERVICE_KEY`	Admin auth, bypasses RLS

Never expose the service key

SUPABASE_SERVICE_KEY bypasses all Row Level Security. Never prefix it with VITE_ — anything prefixed VITE_ is bundled into the browser and visible to the world. Keep it server-side only. See Secrets & Environment.

1.2 Configure redirect URLs¶

Open Authentication → URL Configuration and set the site URL plus every callback your app uses.

Setting	Value
Site URL	`https://<your-domain>` (production) / `https://test.<your-domain>` (test)
Redirect URLs	`https://<your-domain>/auth/callback`
	`https://test.<your-domain>/auth/callback`

Tip

Add the redirect URLs for all environments you operate. A common cause of a failed login is a callback URL that is not on the allow-list.

1.3 Enable TOTP MFA¶

Open Authentication → Multi-Factor and confirm:

Setting	Value
TOTP	Enabled (default)
MFA enrollment	Optional — users opt in via an authenticator app

If TOTP is off, click Enable TOTP.

Part 2 — Google OAuth¶

2.1 Create the Google Cloud project¶

In the Google Cloud Console, click Select a project → New Project, name it App-name, and create it.

Under APIs & Services → OAuth consent screen, choose External (unless every user is in your Google Workspace) and fill in:

Field	Value
App name	`App-name`
User support email	Your admin email
App domain	`<your-domain>`
Authorized domains	`<your-domain>`
Developer contact email	Your admin email

Add the scopes email, profile, and openid.

Test users while in Testing status

While the consent screen is in Testing status, only email addresses added under Test users can complete Google login — a Google security measure. Add your own and your team's addresses, or publish the app to move to Production status where test users are no longer required.

2.3 Create OAuth credentials¶

Under APIs & Services → Credentials, click Create OAuth client and configure a Web application named App-name Web.

Authorized JavaScript origins:

https://<your-domain>
https://test.<your-domain>

Authorized redirect URI (one per Supabase project):

https://<your-supabase-project>.supabase.co/auth/v1/callback

Save the resulting credentials securely — the secret is shown only once:

Credential	Example	Save as
Client ID	`123456789.apps.googleusercontent.com`	`GOOGLE_CLIENT_ID`
Client secret	`GOCSPX-xxxxxxxxxxxxx`	`GOOGLE_CLIENT_SECRET`

2.4 Enable the Google provider in Supabase¶

In Authentication → Sign In / Providers, toggle Enable Sign in with Google on, paste the GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET, and save. The callback URL shown here is the one you registered in Google Cloud.

Part 3 — Microsoft / Azure OAuth¶

3.1 Register the application in Azure¶

In the Azure Portal, go to Azure Active Directory → App registrations → New registration:

Field	Value
Name	`App-name`
Supported account types	Accounts in any organizational directory and personal Microsoft accounts
Redirect URI (Web)	`https://<your-supabase-project>.supabase.co/auth/v1/callback`

3.2 Get application credentials¶

On the Overview page note the Application (client) ID (AZURE_CLIENT_ID) and the Directory (tenant) ID. Then under Certificates & secrets → Client secrets, create a new secret (expiry 24 months recommended) and copy its Value immediately — it is shown only once — as AZURE_CLIENT_SECRET.

3.3 Configure API permissions¶

Under API permissions, add Microsoft Graph → Delegated permissions: email, openid, profile, User.Read. Grant admin consent if you have the rights.

3.4 Enable the Microsoft provider in Supabase¶

In Authentication → Sign In / Providers, toggle Enable Sign in with Microsoft on, paste AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, and the tenant ID (leave blank for multi-tenant), and save.

Part 4 — Environment configuration¶

The hosted project surfaces three core variables. Define the VITE_ pair once; the backend falls back to them when the non-prefixed forms are absent.

# Frontend and backend (shared)
VITE_SUPABASE_URL=https://xxxxx.supabase.co
VITE_SUPABASE_ANON_KEY=sb_publishable_...

# Backend admin only — never prefix with VITE_
SUPABASE_SERVICE_KEY=sb_secret_...

Single source of truth

These secrets live canonically in GitHub and are injected at deploy time into the server .env and containers. See Secrets & Environment for the full strategy.

Part 5 — Verification¶

Confirm the providers are enabled in Authentication → Sign In / Providers:

Provider	Status	Configured with
Google	Enabled	Client ID + secret
Microsoft	Enabled	Client ID + secret + tenant ID
Email	Enabled	Default

Confirm MFA in Authentication → Settings: MFA enabled, TOTP enabled, enforcement optional.

Smoke-test the authorize endpoints (a redirect, not an error, is success):

# Google
curl -I "https://<your-supabase-project>.supabase.co/auth/v1/authorize?provider=google"

# Microsoft (azure)
curl -I "https://<your-supabase-project>.supabase.co/auth/v1/authorize?provider=azure"

Troubleshooting¶

Issue	Cause	Fix
"Unsupported provider: provider is not enabled"	Provider off in Supabase	Enable Google/Microsoft under Sign In / Providers
"redirect_uri_mismatch"	Callback not registered	Add the exact Supabase callback URI in Google/Azure
"Invalid client_id"	Wrong client ID in Supabase	Match the ID to the OAuth console
"Access blocked"	Consent screen unpublished or user not a test user	Publish, or add the email as a test user
`AADSTS50011`	Azure redirect URI mismatch	Add the exact Supabase callback URL
MFA not prompting	User has not enrolled	User must enroll TOTP first

Security checklist¶

[ ] Google and Microsoft OAuth credentials stored only in the Supabase dashboard.
[ ] SUPABASE_SERVICE_KEY lives server-side only, never in the frontend.
[ ] MFA enabled with TOTP configured.
[ ] Google consent screen uses the correct authorized domains.
[ ] Azure app registration has the correct redirect URI.
[ ] Environment files reference the correct per-environment Supabase URL and keys.

Next steps¶

Deploy the application with Supabase Auth wired up, test all three login methods (Google, Microsoft, email), and verify MFA enrollment. Then dig into the runtime sequence in Auth Flow.