All posts
4 min read

"Sign in with Google" Explained: OAuth for Beginners

Social login lets users skip creating a password. How 'Sign in with Google' (and GitHub, Apple, Microsoft) actually works, what OAuth and OpenID Connect are, what redirect URIs and client secrets are, and why it breaks when you move from localhost to your real domain.

getting startedsecuritydeploymentbeginner

"Sign in with Google" buttons are everywhere because they're good for everyone: users don't create yet another password, and you don't have to store one. Setting them up involves a few terms — OAuth, client ID, redirect URI — that sound complicated but describe a simple dance.

What happens when someone clicks the button

  1. Your app sends the user to Google with a note: "This is Plant Tracker (here's our ID). Please confirm who this person is, then send them back to https://plants.example.com/auth/callback."
  2. Google handles the login. The user signs in on Google's own page — your app never sees their Google password — and approves sharing basic information like their name and email.
  3. Google sends the user back to that callback address, with a one-time code.
  4. Your server exchanges the code with Google, directly and privately, proving its identity with a secret. Google replies with information about the user.
  5. Your app logs them in — creating an account the first time, and starting a session. (What Is a Cookie?.)

The whole thing takes a second or two.

OAuth and OpenID Connect

OAuth 2.0 is the standard behind this dance. It was designed for authorization — letting one app access something in another on your behalf, like "let this app read my Google Calendar."

OpenID Connect (OIDC) is a layer on top that adds authentication — "tell this app who I am." When you use "Sign in with Google," you're using OpenID Connect, and the user information arrives as a signed token. (What Is a JWT?.)

In everyday speech, people call all of it "OAuth." (Authentication vs Authorization explains the difference between the two ideas.)

The pieces you'll configure

To add Google login, you register your app in Google's developer console (GitHub, Apple, and Microsoft each have an equivalent). You get and set:

  • Client ID — your app's public identifier. Fine to appear in front-end code.
  • Client secret — a password proving that requests really come from your server. Server only. Never in front-end code, never committed to Git. (How to Keep API Keys Out of an AI-Built App.)
  • Redirect URI (or callback URL) — the exact address Google may send users back to. Google refuses any address not on this list.
  • Scopes — what you're asking for. For login, openid email profile is enough. Ask for more and users see a scarier consent screen.
  • Consent screen — the app name, logo, and privacy policy link users see.

If you use a login service (Supabase Auth, Clerk, Auth0, Firebase) or a library (Auth.js, Better Auth), it handles the dance; you paste the client ID and secret into its settings. That's strongly recommended over building it yourself. (How to Add Login to an AI-Built App.)

Why it breaks in production

The single most common problem: it worked on localhost, and fails on your real domain with an error like redirect_uri_mismatch.

The redirect URI must match exactly — scheme, domain, port, and path. These are all different:

http://localhost:3000/auth/callback
https://plants.example.com/auth/callback
https://www.plants.example.com/auth/callback
https://plants.example.com/auth/callback/

The fix: add your production callback URL (and any www variant) to the list in the provider's console, and set your app's configuration — often a variable like SITE_URL or AUTH_URL — to the production address. If you use a login service, it may also have its own list of allowed redirect URLs to update. (Why Does My App Work Locally but Not in Production?.)

Other production gotchas:

  • HTTPS is required for production redirect URIs. (What Is HTTPS?.)
  • Publishing the consent screen. Google apps start in a testing mode that only allows listed test users. Move to production before launch.
  • Preview deployments with changing URLs may not be on the allowed list, so social login fails there unless you plan for it.

Linking accounts

What if someone signs up with email and password, then later clicks "Sign in with Google" with the same email? Decide deliberately:

  • Link them — but only if the provider confirms the email is verified. Otherwise, someone could claim an email they don't own.
  • Or keep them separate and tell the user to sign in the original way.

Good login services handle this with settings; custom code often gets it wrong.

Which providers to offer

  • Google — the most widely used.
  • GitHub — ideal if your users are developers.
  • Apple — Apple's App Store rules require it in iOS apps that offer other social logins, with some exceptions; popular with iPhone users anyway.
  • Microsoft — common for business users.

Two or three buttons is plenty. Consider keeping email login too, for people who don't want to link accounts.

EasySpawn runs your app on your own domain with automatic SSL from the start, so the redirect URI you register is the real one — no surprise redirect_uri_mismatch on launch day. See how it works or join the waitlist.

Related: What Is a JWT? · Password Hashing Explained · How to Connect a Custom Domain to Your App

Keep reading