How to Add Google Sign-In to a Next.js App With Supabase

Written by: Vladislav Zhirnov
Published: September 13, 2026
Reading time: 18 min read
Topics: #Supabase
#MVP Development

You want someone to open your app, choose Google, and get on with what they came to do. If they already have an account, they should find their existing work when they return.

Google checks which Google account the person is using. Supabase, which already handles your app's accounts, connects that identity to an app account. Your app must then recognize them and open the right page. We'll add that flow to your existing Next.js app, the framework used to build its pages and features.

In my dog-training app, Doogle, I use Google sign-in alongside six-digit email codes. See Doogle (opens in a new tab).

Keep your existing email option. Google gives people another familiar way in. Your AI can handle the connected settings and code; you'll give it access and try the finished experience with real accounts.

Before you start

Your app should already let people create an account, sign in, reload a private page, and sign out. If that foundation is missing, use the account-setup guide linked above first.

Open the existing app in your AI coding tool. Sign in to the Google and Supabase accounts that manage it. Authorize the tool's access when needed; handle your own passwords and account-verification questions.

Start where you test changes. Have AI check its connection to Supabase first: an app running on your computer can still share account settings with the public app.

Have a Google account that is new to your app ready. Also have an existing email user with a Google account at that same verified address, if possible. You'll check both joining and returning to existing work.

Step 01Have your AI check the setup

Have AI find the existing account code, the page people should reach after sign-in, and its available Google and Supabase setup tools.

There are two return trips. Google sends the person back to Supabase. Supabase then sends them back to your app. A return address may be called a callback or redirect URL in the settings. The two services need different addresses because they do different parts of the job.

Your AI should replace these examples with your actual addresses. Supabase's Google setup (opens in a new tab) documents the first return; its app return settings (opens in a new tab) cover the second.

The three addresses your AI needs to identifySwipe or scroll to see every column

What the address does	Example	Where it belongs
Opens your app	https://yourapp.com	Google: Authorized JavaScript origins; Supabase: Site URL
Returns from Google to Supabase	https://YOUR_PROJECT_REF.supabase.co/auth/v1/callback	Google: Authorized redirect URIs
Returns from Supabase to your app	https://yourapp.com/auth/callback	Supabase: Redirect URLs; the app's Google sign-in code

The last example assumes your app uses /auth/callback. AI should inspect or create the actual return handler and use its address. For an active custom Supabase address, use the return address Supabase currently shows.

When the app runs locally but uses hosted Supabase, Google's return address stays with hosted Supabase. Let the actual connection decide.

This inspection prompt produces actual addresses and identifies missing access before settings change. The later prompts can then refer to one agreed setup.

Copyable prompt

Help me add Google sign-in to this existing Next.js and Supabase app. Inspect the installed versions, existing browser/server account helpers, signup and login screens, email methods, return handlers, protected pages and sign-out. Reuse the working foundation. If accounts do not yet work, explain what is missing before adding Google.

Identify the test and public app addresses, their Supabase projects, the Google projects/clients already in use, and the intended signed-in landing page. Build a short environment map with the app origin, Google-to-Supabase return address and Supabase-to-app return address. Use actual values, including an active custom Supabase domain if one exists. Local app code using hosted Supabase still uses the hosted provider return address.

Inspect your actual available tools and permissions. Identify authorized Google browser access and a Supabase management or browser connection that can change sign-in settings. A database tool alone is not enough. I will sign in and authorize access. Keep credentials out of chat.

Do not change settings yet. Show the map, what you can configure directly, and the smallest access step you need from me. If testing would change the live project's settings, explain that shared setup before continuing.

After you run it: Check the app and account names, and which settings belong to the test and public versions. Complete any missing access step, then give AI the setup jobs below.

Step 02Set up your app in Google

Google keeps the app's identity, audience, and sign-in connections inside a Google project. Google's publishing rules (opens in a new tab) require separate projects for testing and the public app, also called production. Two connections inside one project are not enough. Reuse a valid setup if you have one.

Google's sign-in settings live in Google Auth Platform (opens in a new tab), under Audience, Branding, Data Access, and Clients. Google's client settings (opens in a new tab) explain the connection fields. Your AI can operate the browser you authorized. If it cannot, it should give you the exact remaining fields and resume once you finish.

For a public app, choose External as the audience. Internal limits access to the relevant Google organization. Request only the person's basic identity: their account identifier, email address, and profile. Google names these permissions openid, email, and profile. Signing in does not require access to their Gmail, Drive, or Calendar.

Google's Testing rules (opens in a new tab) have a useful exception for those basic identity permissions alone. Users do not have to be on a test-user list, and the usual testing warning and seven-day authorization expiry do not apply. Extra permissions change that. Your AI needs to check what the app actually asks Google for, and work or school accounts can still have their own restrictions.

Supply your real app name, support contact, homepage, and the policy links Google asks for. Google's branding process (opens in a new tab) separates checking the name and logo from publishing them; publishing the app is another setting. Have AI report each state without promising review timing.

Have AI fill in the app information and basic permissions through your authorized Google browser. This prompt keeps test and public settings separate and asks you for missing facts or access.

Copyable prompt

Configure Google sign-in for the test environment we identified. Use the authorized signed-in browser and current Google console pages. Reuse the appropriate Google project; confirm a separate Google project owns the public app. If that separation is missing, propose the specific environment arrangement before replacing working credentials.

Inspect Audience, Branding and Data Access. For this public app, use External and only openid, email and profile permissions. Use my real app name, support contact, homepage and required policy links. Ask for missing factual details; do not invent contact information or legal pages. Follow the actual fields Google requires.

Apply the basic-identity Testing exception only if the requested permissions qualify. Keep app publishing status, brand verification, published branding and any extra-permission review distinct. Set up the test settings without publishing the public app or its branding in this step.

Complete the browser work your access allows. If a step needs me, give the exact page and fields, then resume. Report saved non-secret settings and any pending Google review.

After you run it: Check the selected test project, audience, and permissions. Supply any missing product details before AI creates the connection.

The website connection is called a Web application client. Put the app's base address in Authorized JavaScript origins, with no page path. The full Google-to-Supabase return address belongs in Authorized redirect URIs. These are the two Google fields from your map.

Google gives the connection an identifier, called a client ID, and a private password, called a client secret. Keep the secret out of chat and your app's browser code. New secrets are shown when created, so have your AI save it privately if its tools support that. Otherwise, enter it yourself in Supabase in the next step.

Copyable prompt

Create or reuse the correct Web application client in Google console > Clients for our chosen test project. Inspect an existing client before creating another.

Add the app's exact origin under Authorized JavaScript origins, as Supabase's Google instructions require: scheme, hostname and port when needed, with no path, query or fragment. Add the exact Google-to-Supabase callback from our map under Authorized redirect URIs. Do not substitute the app return address there. Use local addresses only in the development Google project; clients for the public app must keep developer-only addresses out.

Save the client. Transfer the client secret directly into protected credential storage if your tools can handle it privately. Otherwise let me capture it privately for direct entry into Supabase. Never print it in chat, screenshots, saved diagnostic output or tracked files.

Read back the project, client ID, client type, origins and return addresses without exposing the secret.

After you run it: Compare the saved addresses with your map. Keep the private secret available for the Supabase connection.

Step 03Connect Google to Supabase

Supabase's Google provider settings hold the client ID and secret. An authorized connection for changing account settings is called the Supabase Management API. Your AI can use it or the signed-in dashboard, following Supabase's provider setup (opens in a new tab).

A connected Supabase tool may lack controls for account settings. Have AI check. If it cannot handle the secret privately, it should open the Google provider's credential fields for you to enter it.

Supabase also needs to know where people can return inside your app. The default app address is called Site URL. The allowed return addresses (opens in a new tab) are listed under Redirect URLs. The app's full return address belongs on that list; the code in the next step must use the same value.

Keep the addresses your existing email sign-in needs. If testing shares Supabase with the public app, preserve the public Site URL and settle that shared arrangement before changing provider credentials.

This prompt connects Google to Supabase and saves the app's return address. AI reads the current settings first, keeping the values your existing email sign-in needs.

Copyable prompt

Connect the Google web client we configured to the Supabase project in our agreed environment map. Read the current Google provider and URL settings first, without dumping secret fields.

Use the authorized Supabase Management API or signed-in dashboard to enable Google and set the correct client ID and client secret. Check the tool's actual account-settings permissions. Transfer the secret privately, or open the provider credential field for me to enter it. Do not use an app publishable key as management access.

Set Site URL to the appropriate default app address for this environment. Preserve the public default if this is a deliberately shared project. Add our exact Supabase-to-app callback to Redirect URLs, preserving existing needed email and app returns. Prefer exact paths for the public app; do not broaden the list as a workaround for a mismatch.

Apply only the agreed Google and return-address changes. Leave email providers, templates and existing account data intact. Read back the project, Google enabled state, client ID, Site URL and allowed return addresses. Confirm the secret is configured without displaying it.

After you run it: Check that Google is enabled on the right project, with the expected client ID and app return address. Next, connect that setup to the app.

Step 04Add Google sign-in to your app

Put Google beside email on the screens people use to join and return. Follow Google's button guidance (opens in a new tab) for its label, logo, and spacing. Use that presentation with the Supabase account system you already have.

The button starts sign-in; your app must finish the return. Supabase sends back a temporary code. The app exchanges it for its signed-in state, called a session, so it can recognize the person after returning and on a reload.

Your existing email return may do a different job. Have AI inspect it before adding Google's return handling. Supabase's server-side setup (opens in a new tab) explains how the browser and server share the signed-in state. Your AI should use your installed versions and existing account helpers.

I would start with the app's existing landing page after sign-in. Remembering the task someone was trying to open is useful too, provided the app checks that the destination is allowed.

While Google opens, show that the button is working and prevent repeated clicks. If someone cancels, let them choose Google again or use email. A Google cancellation should not tell them to request another email code.

This prompt has AI build the button and return handling using your existing account features. It also covers the waiting and retry behavior people see.

Copyable prompt

Implement Google sign-in in our existing Next.js/Supabase app using the inspected versions and current provider documentation. Add a Google-compliant button to the existing signup and login experience, alongside the current email option. Use our existing browser client and signInWithOAuth with provider google. Set redirectTo to the exact app callback we allowed in Supabase. Request only basic identity access.

Implement or extend the app's return handling for this flow. With the existing per-request server client, exchange the returned authorization code using exchangeCodeForSession and correctly save session cookies in what the server sends back to the browser. Inspect any existing email return handler instead of assuming the flows are interchangeable. Preserve cookie refresh, server-side identity verification and existing account/profile setup. Keep anything that carries one person's sign-in state out of shared caches. Do not add a second account store or put the Google client secret in frontend code.

Use our established signed-in destination. If preserving a next destination, resolve and validate the full destination against trusted app origins and allowed paths; reject off-site or malformed values. Do not trust app addresses from unverified forwarding information.

Add clear pending feedback, prevent duplicate starts, and handle provider errors, missing codes, failed exchanges and cancellation with a useful return to the sign-in screen. Let people retry or choose email. Do not label Google failures as expired email codes.

Run focused automated checks for the changed return handling, invalid destinations, error/retry states and existing email behavior. Show the implemented experience and actual results. Leave real Google-account checks for the next step.

After you run it: Open the sign-in screen and review Google alongside email. Check AI's automated results before trying real accounts.

Step 05Test new and returning users

Have AI run the checks it can operate while you choose Google accounts and complete Google's sign-in questions. The account picker is only the start; check what happens back inside your app.

For an existing email user, use the same verified email address in Google. Supabase's automatic identity linking (opens in a new tab) can attach that Google identity to the existing user. This does not merge arbitrary accounts with different addresses. Accounts using a company's separate shared sign-in system, called SAML, are excluded. Your app's own profile and saved work still need checking.

Use this short sequence to cover joining, returning, and leaving:

Start signed out. Choose Google with an account that is new to your app. Confirm that you reach the intended page as the right person.
Complete any first-visit setup and save a little test work. Reload and check that the app still recognizes you.
Sign out of the app. Confirm that a private page requires sign-in again. Return with the same Google account and find your test work.
Try the existing email user through Google with that same verified address. Check the expected account and saved work.
Cancel a Google attempt where the screen allows it. Check that you can retry or choose email without a stuck loading button.
Use the existing email option again and confirm that it still reaches the expected app account.

App sign-out leaves your Google account signed in, so Google may recognize you quickly next time. Adding Google also does not create a password for an account that never had one. Check the email method your app actually supports.

This prompt has AI run checks and guide your real-account steps. It asks for a specific repair and retest after failures, and keeps anything you could not try marked as untested.

Copyable prompt

Test the new Google sign-in flow in the agreed test environment. Run the browser checks your access permits; I will choose accounts and handle Google's sign-in and verification questions.

Cover a new-to-app Google user, return with the same Google account, reload of a protected page, app sign-out, and the existing email option. For an existing user with the same verified email, check the actual Supabase user identity and expected app profile/data, not just the displayed address. Do not add manual linking or merge accounts to force a pass.

Check cancellation and retry where the real Google flow permits them. Exercise failed code exchange, missing return data, unsafe destinations and stuck pending states in local tests without breaking live provider settings. Verify the outgoing Google scopes are only the basic identity scopes we chose.

Report each actual outcome, any fix and its retest. Distinguish automated checks from my real-account observations. List unavailable accounts or device checks as untested. Keep credentials and personal account details out of screenshots and reports.

After you run it: Compare the results with the sequence above. If a returning user reaches an empty account, have AI check why before you add more data. Finish any remaining real-account checks.

Google rejects a return address

For redirect_uri_mismatch, have AI compare the address sent to Google with Authorized redirect URIs in the client Supabase actually uses. It should be the full Google-to-Supabase address.

Check the https part, hostname, path, capitalization, and trailing slash. Correct it, allow time for Google's settings to take effect, and start a fresh attempt. Supabase's app-return list controls a different step.

Your app opens signed out

For the wrong page, inspect the app return address and Supabase's allowed list. For the right page but no signed-in account, have AI check the code exchange and saved sign-in state.

If it works until you reload, have AI inspect the browser and server account helpers and cookie handling. Supabase's return-handling guide (opens in a new tab) explains how that state is shared.

Google will not let this account continue

Have AI read Google's message and check the audience and actual permissions. An organization-only app or a work account's restrictions can change who is allowed in.

Adding everyone as a test user may not help. Check whether the basic-identity exception applies. If the app asks for more access, have AI explain why before you grant it.

Step 06Check Google sign-in on the published app

Publish the reviewed change through your normal process. Its Google connection belongs in the separate public Google project. Have AI confirm the public app's Supabase project and full return address.

Check Google's public-app settings, product information, and any unfinished review. Use secure https addresses. Google's production guidance (opens in a new tab) keeps developer-only addresses out of the public connection.

Open the address your users will visit. Choose Google, return to the right account, reload, and sign out. Repeat on a phone. If users arrive through a browser inside another app, test that entry separately; the desktop result cannot tell you how it behaves.

Have AI inspect the published app and list the checks that still need your device or account. Try those yourself. The person should get back to their app and their work.

This prompt carries the tested change through publishing and checks the public address. It keeps the Google projects separate and identifies real phone checks that need you.

Copyable prompt

Prepare the reviewed Google sign-in change for our normal publishing process. Use the separate Google project for the public app and the intended public Supabase settings. Confirm the public app origin, Google-to-Supabase return address, Supabase-to-app return address, default app URL and existing email returns. Keep developer-only origins and redirects out of the public Google client.

Check current Google Audience, Branding and Data Access settings, actual outgoing identity scopes, required public product links, and any remaining review. Complete setup through authorized tools. Ask before replacing shared live credentials or publishing if that action is not already authorized. Keep app publishing, brand verification and published branding distinct.

After the reviewed change is published, open its actual public address and repeat new/returning Google sign-in, expected account/data, reload, sign-out and the existing email option. Check cancellation/retry as available. I will repeat the important path on my phone and any in-app browser our users rely on.

Report the exact public address, what you actually tested, fixes and retests, and what still needs my device or account. Save a short non-secret setup note with the project/client names, addresses and results so later changes use the right settings.

After you run it: Finish the untested phone and account checks. When the public app returns people to the expected account and their work, Google sign-in is ready to use.

You may see a Supabase address on Google's screen. Once sign-in works, you can replace the visible Supabase address with your own domain using the separate guide linked here. Treat that as the next refinement; finish the working Google sign-in first.

Still having trouble?

Pull me into your project with @Vlad, your virtual co-founder. Or, if you'd rather work with the real me, set up a call.

Get @Vlad Setup a Call

Summary

The finished experience is straightforward: choose Google, return to the app, and keep using the expected account. Google checks the person, Supabase handles the account, and your app finishes the return.

Let your AI handle the settings, code, and repeatable checks. Use your own accounts and phone to see what people will actually experience. Once that works, spend your attention on what they came into the app to do.

About the author

Vladislav Zhirnov

Co-Founder and CPO at Pinpoint

I'm Vladislav Zhirnov, Co-Founder and CPO at Pinpoint (opens in a new tab). There, I lead product strategy, contribute to early growth, and build AI systems that enable us to iterate quickly. Through this site, I help founders and product teams turn promising apps into successful products real people use.

Before this chapter, I spent more than five years at Side (opens in a new tab), growing from Product Manager Trainee to Director of Product Management. There, I led DUBS - a social gaming platform for teens - from concept to over 150,000 installs.

Away from the screens, I live on a homestead with Carl the mini-Highland cow and a rather large supporting cast.

To learn more about Pinpoint and the other projects I'm involved in, visit my portfolio.

Learn more about me

Sources

13 references

Show 5 more references

Choose your next move

Keep moving from idea to real use.

App Readiness CheckCheck the rest of your app before real people do.Use the App Readiness Check to find the next signup, data, payment, or publishing gap that could stop a real user.Check Your App Virtual Co-FounderBring @Vlad into the project.Bring @Vlad into the project to untangle a hard problem and turn the next move into a plan.Get @Vlad Hands-on helpWork directly with Vlad.Get direct help finding the actual problem and moving your app, AI system, or workflow toward real use.Setup a Call

Scan my page