Skip to content

Guides

Give an AI-built app Google sign-in without a Google Cloud project

People choose Google, see Tofu’s consent screen and return signed in to your app. Tofu provides the Google connection; your app provides the button and decides what each person can access.

Updated

The short answer

Host the app on Tofu with a running Tofu-managed database, then have its Google button send visitors through Tofu's sign-in service. Tofu handles the Google connection and creates a session in the app's own sign-in service. You do not create a Google Cloud project or copy a Google secret.

The app still needs to read that session and enforce its own access rules. A button that calls supabase.auth.signInWithOAuth directly uses a different route; it does not become a Tofu sign-in button just because the app is hosted here.

What you need

  • A deployed app and a running managed database. Tofu uses the app's recorded address to return the person to the right app, and its own database to hold the account.
  • Sign-in available for this app. The Tofu sign-in entry point below works for any app with a running managed database, whatever the plan. Turning Google on in the app's own Sign-in settings follows the plan's allowance. The app's Sign-in page reports any hosting or setup limitation; the pricing page lists allowances.
  • App code that handles a signed-in person. A Google button, a Supabase client connected to this app's database, and rules for what each person may see and change.

Step by step

  1. Put the app and its database online

    Send the app to Tofu through a coding agent or a repository import, and approve creating its managed database. The Database page shows when it is ready. If this app already uses a database or sign-in service elsewhere, moving that service is a separate job; Tofu writes no Google configuration into your external account.

  2. Connect the Google button to Tofu

    Have the app's code use the entry point shown below. For a browser app, the Supabase client reads the session returned in the address. A server-rendered app needs a callback route that verifies the returned token and sets its session cookies. The server sign-in docs cover that route.

  3. Check the app’s sign-in settings

    The Sign-in page can turn on Google in the app's own sign-in settings, and a connected coding agent can do the same after you approve. That writes Tofu's Google client, return address, email sign-in and sending setup. It is separate from the button's Tofu route, which does not depend on the Google switch in those settings. Read the status message as well as the switch.

  4. Try the journey as a visitor

    Open the published app and choose Google. Google shows Tofu's name, because Tofu owns the Google connection. Choose an account and approve on Google's screen. You return to the app signed in; the account is stored in this app's database. If sign-up is limited to people you add, a new person needs to be added first.

  5. Check what a signed-in person can access

    Save something, reload and sign out. Then sign in with another account and check that the first person's private records are inaccessible. Login identifies the person; the app's server and database access rules protect the records. The Sign-in page's people list can confirm a Google sign-in with its last sign-in time.

What the app’s Google button calls

For a browser app using Supabase's normal session handling, the button redirects to Tofu with the app's return address. This example returns to the app's home page and leaves out any old sign-in fragment:

The Google button in a browser appjs
const returnTo = new URL("/", window.location.origin).href;
window.location.href =
  import.meta.env.VITE_TOFU_SIGN_IN_URL + "?return=" + encodeURIComponent(returnTo);

Tofu writes TOFU_SIGN_IN_URL onto the app with its managed database, with a browser copy under the framework's prefix (VITE_ above, NEXT_PUBLIC_ in Next.js). It is not a secret, so the app never writes Tofu's address itself.

The return address must be an HTTPS address Tofu records for this app, such as its published Tofu address or a connected custom domain. An arbitrary address, another host or a local preview is not a valid destination, so try sign-in on the published address. The Supabase client must point at the app's managed database and read the returned session.

For a server-rendered app, the return address is its callback route and the URL also includes &flow=pkce. That route calls supabase.auth.verifyOtp with the returned token_hash and type, then stores the session in cookies. Adding the URL alone does not implement that route.

If the existing button uses supabase.auth.signInWithOAuth, it goes through Supabase's own Google configuration instead. That route also needs the app's callback registered on Tofu's Google client, an operator step. The Tofu entry point above avoids a registration for each new app.

Who does what

Part of sign-inTofu handlesYour app handles
The Google connectionThe Google client, consent screen and return from Google.A button that sends the person through Tofu’s sign-in entry point.
The signed-in sessionA session in the app’s own managed sign-in service after Google verifies the person.Reading that session in the browser, or verifying it in a server callback and setting cookies.
The person’s accountThe verified email address, name and profile picture in the app’s own account.Any additional profile fields or onboarding the app requires.
Private recordsThe identity that the app’s access rules can check.Rules on the server and database for who may read or change each record.

What Tofu does not do

  • Show your brand on Google’s consent screen. People see Tofu’s verified name. Bringing your own Google client for a different brand is not part of this setup.

  • Grant access to Gmail, Drive or Calendar. This signs the person into your app. It returns no Google provider token, so reading their Google services requires a separate integration and permission.

  • Configure someone else’s sign-in service. The managed setup uses the database Tofu created for this app. It does not configure your own Supabase project, Clerk or Auth0.

  • Create private-data rules just by enabling login. A hidden button is not an access rule. The app’s server and database must check the signed-in person for every protected operation.

Questions

Do the app’s users need Tofu accounts?

No. This Google button creates or finds an account in your app's own sign-in service. It does not sign the visitor up for the Tofu dashboard.

Why does the Sign-in page say Google is off when the button works?

That switch describes the Google configuration in the app's own sign-in service. A button going through Tofu's entry point uses Tofu's connection instead. The page's status message explains the difference. A completed sign-in is confirmed by the person's Google method and a last sign-in time after the attempt.

Does Google sign-in make the whole app private?

No. It gives the app a way to identify a person. The app must require that session where needed and protect its data. Choosing who can open the whole app is a separate sharing setting.

Can the same person also sign in by email?

The account uses the email address Google verified. An emailed sign-in link to the same address reaches the same account when the app offers that method. Email screens and the confirmation route still belong to the app's code.

Does it work on a custom domain?

Yes, after the domain is connected to the same app in Tofu. The return address must match an address Tofu records for that app. Try the full sign-in journey again after connecting the domain.