How to Set Up Google, Apple, Microsoft, and Facebook Login with Supabase Auth

This guide walks through a practical web setup for four common identity providers with Supabase Auth:

  • Google
  • Apple
  • Microsoft, shown as Azure in Supabase
  • Facebook

The examples use placeholder values so you can adapt the steps to any app.

What You Need Before Starting

Create or confirm these first:

  • A Supabase project.
  • A production website domain with HTTPS, such as https://example.com.
  • A local development URL, such as http://localhost:5173.
  • Admin access to Google Cloud, Apple Developer, Microsoft Entra/Azure, and Meta for Developers.
  • Public pages for privacy policy, terms of service, and data deletion instructions. Facebook usually requires all three. Google, Apple, and Microsoft may also show these during app review or consent setup.
  • A secure place for secrets outside your Git repository.

Use a business or organization account to own provider apps whenever possible. The app can still allow personal users to sign in, but the OAuth credentials should not depend on one person's personal account.

Know the Two Types of Redirect URLs

There are two redirect concepts that often get mixed up.

1. Provider Callback URL

This is where Google, Apple, Microsoft, or Facebook sends the user after provider authentication. For Supabase Auth, the provider callback URL normally follows this pattern:

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

Use this URL inside Google, Apple, Microsoft, and Facebook developer consoles.

2. App Redirect URLs

These are the URLs where Supabase is allowed to send users after Supabase finishes creating the session.

In Supabase, go to:

Authentication -> URL Configuration

Set:

Site URL: https://example.com

Add redirect URLs for the places your app can safely return users to:

https://example.com/**
https://www.example.com/**
http://localhost:5173/**

For production, exact redirect URLs are stricter and safer. Wildcards are convenient for development and preview deployments, but do not make them broader than needed.

Client-Side Login Code

Supabase provider IDs are:

google
apple
azure
facebook

Microsoft login uses the provider ID azure.

Example with @supabase/supabase-js:

async function signInWithProvider(provider) {
  const options = {
    redirectTo: `${window.location.origin}/`,
  };

  if (provider === "azure") {
    options.scopes = "email";
  }

  const { data, error } = await supabase.auth.signInWithOAuth({
    provider,
    options,
  });

  if (error) throw error;
  return data;
}

Microsoft/Azure needs the email scope because Supabase Auth requires Azure to return a valid email address.

Google Login

Google Console Setup

Open Google Cloud Console or Google Auth Platform and create or select a project.

Configure the consent screen:

  • App name
  • Support email
  • App logo if available
  • Authorized domain, such as example.com
  • Privacy policy URL
  • Terms of service URL
  • Test users while the app is in testing mode

Create an OAuth client:

Application type: Web application
Name: Your App Web

Add Authorized JavaScript origins:

https://example.com
https://www.example.com
http://localhost:5173

Add Authorized redirect URIs:

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

Copy:

  • Client ID
  • Client secret

Supabase Setup

Go to:

Authentication -> Providers -> Google

Enable Google and paste:

Client ID
Client secret

Save, then test the Google login button from your app.

Common Google Issues

redirect_uri_mismatch means the redirect URI in Google does not exactly match the Supabase callback URL.

If only test users can sign in, your Google app is still in testing mode. Add test users or publish the app when ready.

Apple Login

Apple is the most complex provider because web OAuth uses a Services ID, a private key, and a generated client secret.

Apple Developer Setup

You need an Apple Developer account.

In Apple Developer:

Certificates, Identifiers & Profiles -> Identifiers

Create or choose an App ID and enable:

Sign in with Apple

Then create a Services ID for the web app:

Identifiers -> Services IDs -> New

Use a reverse-domain identifier such as:

com.example.web

This Services ID becomes the Apple Client ID used in Supabase.

Configure Sign in with Apple for the Services ID.

Domains and subdomains usually include:

<project-ref>.supabase.co
example.com
www.example.com

Return URL:

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

Apple expects domains without https:// and without paths. Return URLs must include https://.

Create the Apple Key

Go to:

Certificates, Identifiers & Profiles -> Keys -> New Key

Enable:

Sign in with Apple

Download the .p8 key file once and store it securely. Apple will not let you download the same private key again.

Record:

  • Team ID
  • Key ID
  • Services ID
  • .p8 private key

Generate the Apple Client Secret

For Supabase's Apple OAuth flow, the Apple secret is a JWT signed with your .p8 key.

You need:

Team ID
Key ID
Services ID
.p8 private key

Supabase provides a browser-based helper in its Apple provider documentation. You can also generate the JWT yourself in a secure local script.

Apple OAuth secret keys expire every 6 months. Set a calendar reminder to rotate the Apple client secret before it expires.

Supabase Setup

Go to:

Authentication -> Providers -> Apple

Enable Apple and enter:

Client IDs: your Services ID, for example com.example.web
Secret Key: generated Apple client secret JWT

Save, then test Apple login.

Common Apple Issues

invalid_client usually means one of these is wrong:

  • Services ID
  • Team ID
  • Key ID
  • Generated secret JWT
  • Expired Apple secret
  • Website domain or Return URL

Apple only provides the user's full name during the first authorization. If your app needs a name, capture it during first sign-in or ask for it during onboarding.

Microsoft Login

Supabase calls Microsoft login Azure.

Microsoft Entra Setup

Use a business account to own the app registration if this is for a business product.

Open:

Microsoft Entra admin center

or:

Azure Portal -> Microsoft Entra ID

Go to:

App registrations -> New registration

Use:

Name: Your App Web

Choose supported account types based on your audience:

Public app:
Accounts in any organizational directory and personal Microsoft accounts

Internal company app:
Accounts in this organizational directory only

Personal Microsoft accounts only:
Personal Microsoft accounts only

For a public website, choose the option that includes personal Microsoft accounts so Outlook, Hotmail, Live, and organizational Microsoft accounts can sign in.

Set Redirect URI:

Platform: Web
Redirect URI: https://<project-ref>.supabase.co/auth/v1/callback

Click Register.

Copy:

Application (client) ID

Create a client secret:

Certificates & secrets -> Client secrets -> New client secret

Copy the secret Value immediately. Do not copy the Secret ID by mistake.

Supabase Setup

Go to:

Authentication -> Providers -> Azure

Enable Azure and enter:

Application (client) ID
Secret Value

Azure Tenant URL is optional:

  • Leave it blank for the default common Microsoft tenant, which generally supports broad Microsoft account sign-in based on your app registration.
  • Use https://login.microsoftonline.com/consumers for personal Microsoft accounts only.
  • Use https://login.microsoftonline.com/<tenant-id> if the app should be restricted to one organization tenant.

Code Requirement

Request the email scope in your app code:

await supabase.auth.signInWithOAuth({
  provider: "azure",
  options: {
    scopes: "email",
  },
});

Recommended Microsoft Security Check

Supabase recommends adding the optional xms_edov claim in Microsoft Entra so Supabase can determine whether the email address from Microsoft is verified.

In Microsoft Entra:

App registrations -> Your app -> Manifest

Back up the manifest first, then add optional claims for email and xms_edov as described in the Supabase Azure provider documentation.

Common Microsoft Issues

If login works but Supabase does not create a complete user profile, check that your app requests:

email

If local development fails, use localhost, not 127.0.0.1, because Azure has redirect URI restrictions around local hosts.

Facebook Login

Meta App Setup

Open:

Meta for Developers

Create an app or open your existing app.

In:

App settings -> Basic

Fill in:

Display name
App domains
Contact email
Privacy policy URL
Terms of service URL
User data deletion URL
Category
App icon

App domains should include every domain used in the Facebook OAuth URL:

example.com
www.example.com
<project-ref>.supabase.co

Save changes.

Facebook Login Settings

Go to:

Use cases -> Authenticate and request data from users with Facebook Login -> Customize

Under Permissions and features, confirm:

public_profile: Ready for testing
email: Ready for testing

If email is missing, add it.

Then go to:

Facebook Login -> Settings

or:

Use cases -> Facebook Login -> Settings

Add this exact Valid OAuth Redirect URI:

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

Enable these if shown:

Client OAuth Login
Web OAuth Login
Enforce HTTPS
Use Strict Mode for Redirect URIs

Save changes.

Supabase Setup

Go to:

Authentication -> Providers -> Facebook

Enable Facebook and enter:

Facebook App ID
Facebook App Secret

Save, then test Facebook login.

Common Facebook Issues

Can't load URL usually means the domain in the OAuth URL is not listed in Meta App Domains. Add all relevant domains, including www.example.com and <project-ref>.supabase.co.

Invalid Scopes: email means the Facebook app has not enabled the email permission in the Facebook Login use case.

Redirect URI mismatch means the Valid OAuth Redirect URI in Facebook does not exactly match:

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

If testing works for you but not for other people, the Facebook app is probably still in Development mode. Add testers or publish the app after completing Meta's requirements.

Testing Checklist

Test each provider in a clean browser session:

  • Google opens consent and returns to your app signed in.
  • Apple opens Apple ID login and returns to your app signed in.
  • Microsoft opens Microsoft login and returns to your app signed in.
  • Facebook opens Facebook login and returns to your app signed in.
  • Supabase Auth Users shows the new user.
  • The user has an email address.
  • Your app creates or loads the user's profile correctly.
  • Logout works.
  • Login works again with the same provider.

Also test:

  • Production domain.
  • www domain if your app uses it.
  • Local development URL.
  • Mobile browser.
  • A non-admin/test user before public launch.

Security Checklist

  • Never commit OAuth client secrets.
  • Store secrets in private environment files or a secret manager.
  • Rotate any secret that was pasted into chat, screenshots, logs, or issue trackers.
  • Use organization-owned provider apps for production systems.
  • Set reminders before Apple and Microsoft secrets expire.
  • Keep provider app owners/admins documented.
  • Remove localhost redirect URLs from production provider apps if they are no longer needed.
  • Keep privacy, terms, and data deletion pages accurate.

Quick Reference

Supabase provider IDs:

Google: google
Apple: apple
Microsoft: azure
Facebook: facebook

Provider callback URL:

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

Common Supabase app redirect allow list:

https://example.com/**
https://www.example.com/**
http://localhost:5173/**

Microsoft/Azure code option:

options: { scopes: "email" }

Official References

at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)