Google OAuth client

Prepare these credentials before deployment if you want customers to sign in with Google. Email sign-in works without them, so you can skip this guide if you're not offering Google sign-in yet.

Google uses a client ID and client secret, rather than an API token. Save both in your hosted Supabase project's Google provider settings. They don't belong in the root .env, Vercel variables or browser code.

Create and connect your credentials

Complete the first Kickstart before these steps so you have a hosted Supabase project and its callback URL.

Prepare your Google project

Sign in to Google Cloud Console. Use the project picker at the top to select a project for your app, or choose New project and give it your app's name. Google Cloud projects are free; this one only holds your sign-in settings.

Open Google Auth Platform from the menu or search bar. If it asks you to get started, follow its prompts. Then complete these sections in its sidebar:

Branding: enter your app's name and a support email. Customers see these on Google's consent screen.
Audience: choose External so any Google account can sign in. A new app starts in Testing, where only the accounts listed under Test users can sign in. Add your own Google account there for now.
Data Access: add the openid, .../auth/userinfo.email and .../auth/userinfo.profile scopes. These are all Supabase needs for basic sign-in.

Google's screens change from time to time. If yours differ, follow the current Supabase Google setup instructions.

Copy your Supabase callback URL

In Supabase, open the project created for this app. Go to Authentication → Sign In / Providers → Google and copy the callback URL shown there.

It normally looks like this:

Example callback shape — use your project's actual URL

https://YOUR_PROJECT_REF.supabase.co/auth/v1/callback

Use the URL from your own project. This is where Google returns the sign-in result to Supabase; it isn't your app's dashboard URL.

Create a web client in Google

Return to Google Auth Platform → Clients, choose Create client and select Web application. Give the client a recognizable name for your app.

Under Authorized JavaScript origins, add each address your app runs at, without a path: http://localhost:3000 for local testing and your live address, such as https://your-app.example.
Under Authorized redirect URIs, paste the exact Supabase callback URL from the previous step.

Create the client and copy its client ID and client secret. Keep the secret out of screenshots and agent chat.

Save the credentials in Supabase

Return to the same Supabase project's Google provider settings. Paste the client ID and client secret into their matching fields, enable the provider and save.

Keep Supabase's site URL and allowed application redirects aligned with the app address you're using. Kickstart manages the app's callback allowlist; deployment updates it for the production origin.

What Kickstart handles

Kickstart reports Google provider status and manages the app's allowed callback URLs. It doesn't create a Google OAuth client or enter, store or deploy the Google client credentials for you. Those are the manual steps above.

Your local app and the default deployment share the same hosted Supabase project. Check the active app URL when testing redirects, especially after deployment changes the hosted configuration.

Open your app and choose its Google sign-in button. Use an account allowed by your Google audience settings, complete consent and confirm that you return to the app with a working session and workspace. Reload, sign out and sign in again.

If Google reports a redirect mismatch, compare its authorized redirect URI with the callback shown in Supabase. If the app says Google is unavailable, check that the provider is enabled and its credentials are saved in the correct project. Audience restrictions and test-user settings can also prevent an account from signing in.

Before launch, return to Audience and choose Publish app so accounts outside your test users can sign in. Google may ask you to verify your app's branding first. A successful test sign-in only proves it works for your test users. The authentication guide covers the app's other sign-in methods and session checks.

Back to Accounts

Review the remaining deployment accounts.