Set up Sign in with Google

Sign in with Google puts a Google button on your hosted sign-in page. The person presses it, picks their Google account on Google's own screen, and comes back to your app signed in, with no password to make up. It suits almost any app: most people already have a Google account, from Gmail or from work. You make an OAuth client in Google Cloud (OAuth is the standard way one site lets another confirm who someone is), copy two keys from it into BuildBase, and copy one address from BuildBase back into Google.

What goes where

The last row is only for Google One Tap. A Google client ID ends in .apps.googleusercontent.com, such as 123456789012-abc123def456.apps.googleusercontent.com. A client secret starts with GOCSPX-. The ID is not secret. The secret is: keep it like a password.

1. Make the OAuth client at Google

These steps are the ones the console shows under How to get your Google keys.

1. Open the Credentials page in Google Cloud and sign in with the Google account that should own this. Choose a project at the top of the page, or make a new one, such as Acme Analytics.
2. If Google asks you to set up its consent screen (Google Auth Platform) first, give your app's name and a support email, such as Acme Analytics and [email protected]. This is what your users see when they sign in. While Google lists the app's publishing status as Testing, only the test users you add there can sign in, so publish it before you launch.
3. Choose Create credentials, then OAuth client ID, and choose Web application as its type. Give it any name, such as Acme Analytics sign-in.
4. Google then shows a Client ID and a Client secret. Copy both. Keep this tab open: you come back to it at the end of the next part.

2. Add Google in the BuildBase console

1. In the console, open User management, then Authentication under Access, and the Methods tab.
2. Press Add auth method and choose Google. The dialog says what Google sign-in is for and opens How to get your Google keys, the steps above.

3. Fill in the form:
   • Title: your own name for the method, shown in the console only. The button your users see always says Google. Keep Google.
   • Client ID and Client secret: paste them from Google Cloud.
   • Google One Tap: leave it Off for now. Google One Tap explains turning it on.
   • Scopes: keep the three defaults. They ask Google for the person's email address, their name and picture, and to confirm who they are (openid). A new account is made with the email address, so never remove https://www.googleapis.com/auth/userinfo.email.

4. Not sure where a value is? Press the ? beside its label. Each note says what the value is, where Google shows it, and whether it is secret.

5. Press Create. The dialog now says One step left and shows the redirect URL under Authorized redirect URIs. Press Copy.

6. Press Done. Google is now in the Login methods list.
7. Back in Google Cloud, open the same OAuth client, add the URL under Authorized redirect URIs, and press Save. Google notes that a change can take from a few minutes to a few hours to apply.

The redirect URL has this shape, with your organization's ID and the method's own ID in it:

https://api.console.buildbase.app/api/v1/auth/social/google/<orgId>/<methodId>/callback

It starts with your BuildBase server, https://api.console.buildbase.app{/* @endstat */} on BuildBase's cloud. Copy it from the console rather than typing it: Google checks it letter for letter, so a missing character or a trailing slash fails every sign-in. It never changes while the method exists. Deleting the method and adding Google again makes a new one, which you would have to register again, so edit the method instead.

The secret is never shown again. When you edit the method later, the Client secret box is empty and the line under it shows the saved secret's first and last five characters, such as Saved: GOCSP..ecret. Leave the box empty to keep it, or paste a new secret to replace it.

3. Attach it to your app

A method shows on a sign-in page only once it is ticked on an app.

1. Open the Settings tab and press Edit on Acme Analytics.
2. Under Methods, tick Google and press Update. The console says Client saved.

4. Check the preview

Open the Sign-in page tab. The Preview shows your look on a sample card. Its social buttons are always GitHub and Google, whatever your app offers, so it shows where social buttons sit and how they look, not which ones you have. Two settings on the same tab, under Layout, change them: Social buttons placement (Above the form or Below the form) and Social buttons style (Buttons with names or Icons only).

To see your real page, press Open the live page for Acme Analytics above the preview. It opens in a new tab.

5. What people see

The hosted sign-in page now has a Google button under the email and password form, after or. The register page has it too.

On a phone the button runs the full width of the screen:

Pressing it opens Google's own screen, where the person picks an account and, the first time, agrees to share their name and email address with your app. Google then sends them back, and the sign-in page carries on as after any sign-in: a second step if your two-step policy asks social sign-ins for one, the Trust this device? question, and the passkey offer if your app offers passkeys. Then they are in your app.

The first sign-in

BuildBase looks for the person's account in this order:

1. By their Google user ID. Anyone who has signed in with Google here before is found this way, even if their email address has changed since, here or at Google.
2. By email address, when Google says the address is verified. An account with that address, made with a password or another provider, gets Google connected to it, so step 1 finds it next time.
3. A new account, if sign-up is open to this address (see who can sign up), or the sign-in started from an invitation, and your plan has room for another user. It takes the name and email address from Google, and the address counts as verified, so no code is emailed.

Someone who signed up with Google has no password. They can make one later with Forgot password? on a client that offers email and password. Social sign-ins skip two-step sign-in unless Also ask social sign-ins is on.

In your app

Nothing changes in your code: signIn() from the SDK sends people to the hosted page, and the Google button is there. Inside your app, people see and remove their connected accounts on the SDK's Security screen, and connect Google to an account they made another way. Account security screens shows it.

import { useSaaSAuth } from '@buildbase/sdk/react';

export function SecurityButton() {
  const { openWorkspaceSettings } = useSaaSAuth();
  return (
    <button onClick={() => openWorkspaceSettings('security')}>Security</button>
  );
}

Check it works

• Google is in the Login methods list on the Methods tab.
• The redirect URL from the console is under Authorized redirect URIs on the same OAuth client, saved.
• Google is ticked on your app in the Settings tab.
• Open the live page shows the Google button.
• Signing in with a Google account that is not yet a user creates one, and it appears under Users.
• Signing in again with the same Google account reaches the same user.

Things to watch out for

• Publish the consent screen before launch. While Google lists the app as Testing, only the test users you add there can sign in, up to 100 of them. Everyone else is refused on Google's page.
• A company's Google Workspace administrator can block outside apps. Workspace lets an administrator refuse sign-in to apps they have not approved. With the default scopes your app asks only for basic profile details, which passes the setting that allows those, but not the one that blocks every outside app. Then the person's administrator has to approve your app.
• Finish at Google within 10 minutes. A sign-in left open on Google's page for more than 10 minutes cannot finish: BuildBase sends the browser to your sign-in page, with a note that the sign-in expired. Start again from your app's Sign in button.
• Keep the default scopes. A new account is made with the email address, so without https://www.googleapis.com/auth/userinfo.email nobody new can sign up.

If something goes wrong

This is what the sign-in page shows when someone cancels at Google:

The form stays under the message, so the person can try again or sign in another way.

Next steps

• Google One Tap - one-click sign-in for people already signed in to Google.
• Social providers - the reference: scopes, account lookup and every refusal.
• Account security screens - connected accounts inside your app.
• Set up sign-in, step by step - every sign-in guide, and the order to set them up in.