For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/google-sign-in.md (or send Accept: text/markdown).
Add Google sign-in
Create a free Google Cloud OAuth client and wire Continue with Google into the app.
Beginner walkthrough
Prerequisites: the web app running locally (Ship in 5 minutes) and a migrated database for real accounts (Set up database). You need an ordinary Google account; everything here is free and takes about 10 minutes.
Quick terms: OAuth is the standard where Google signs the user in on Google's page and hands your app a proof. A Google Cloud project is a container in Google's console that holds your app's credentials. The OAuth consent screen is the page Google shows users before sending them back. A client ID identifies your app to Google; the client secret is its password and stays on the server.
1. Create a Google Cloud project. 2. Configure the consent screen. 3. Create one Web OAuth client and copy its ID and secret. 4. Paste three values into apps/web/.env.local and restart the dev server.
One project is enough for the whole product: the same Google Cloud project later hosts your Cloud Run deployment, and mobile sign-in flows through the same web backend — you do not create a separate client per platform or feature.
Create the Google Cloud project
1. Open console.cloud.google.com and sign in with your Google account.
2. Click the project dropdown in the top bar (next to the Google Cloud logo) and choose New Project.
3. Give it a name — your product name is fine — and click Create. No organization, card, or billing account is needed for sign-in credentials.
Expected: the console reloads into the new project, and its name appears in the top bar. Reuse this project when you reach the deployment guide instead of creating another one.
Configure the OAuth consent screen
1. In the left navigation open APIs & Services → OAuth consent screen and click Get started.
2. Enter the App name users will see (your product name), pick a User support email, choose External for the audience, fill in the developer contact email, and click through to Create.
3. Nothing else is needed on this screen: the app requests only the default openid, email, and profile scopes, which require no extra scopes or verification.
Publishing status stays Testing while you develop. In that mode only listed accounts may sign in, so add your own Gmail address under Audience → Test users — otherwise Google blocks even you. When the product is live, click Publish app; because no sensitive scopes are requested, publishing does not start a Google verification review.
Create the OAuth client
1. Open APIs & Services → Credentials → + Create Credentials → OAuth client ID.
2. Set Application type to Web application and name it something like supastack local.
3. Under Authorized JavaScript origins add http://localhost:3000. Under Authorized redirect URIs add http://localhost:3000/api/auth/callback/google — that callback path belongs to Better Auth, the kit's default auth engine: {APP_URL}/api/auth/callback/google.
4. Click Create and copy the Client ID and Client Secret from the dialog. You can reopen them on the client's page later, but copying now saves a step.
For production create a second Web client (recommended) or add to this one: JavaScript origin https://yourdomain.com and redirect URI https://yourdomain.com/api/auth/callback/google. Keeping separate clients per environment means a leaked local secret cannot reach production.
Add the values to the app
Open apps/web/.env.local — Next.js reads this file, not the root .env — and set the three lines below. AUTH_GOOGLE_ENABLED=true turns the button on; the client pair identifies your Google Cloud client.
The client secret is server-only: it must never appear in a NEXT_PUBLIC_ or EXPO_PUBLIC_ variable and never be committed to Git. In production, set the same three names in your host's secret store instead of an env file.
Restart the dev server after editing — environment changes are only read at startup.
# apps/web/.env.local
AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=your-client-id.apps.googleusercontent.com
GOOGLE_CLIENT_SECRET=your-client-secretVerify and troubleshoot
Open http://localhost:3000/auth, click the Google button, complete Google's consent screen, and confirm the app comes back signed in.
redirect_uri_mismatch means the redirect URI registered in Google does not match exactly — check the protocol (http vs https), the port, and the path: it must end /api/auth/callback/google, not /callback/google/ or a trailing slash variant.
Access blocked / has not completed the Google verification process means the consent screen is still in Testing and the signing-in account is not listed under Test users — add it under the Audience section.
If the Google button is missing or sign-in still fails after editing .env.local, restart the dev server. If startup fails naming a variable, the flag is enabled without its complete client pair.