Google Login Configuration

Google login is one of the most common third-party login methods for SaaS products. It fits global users, enterprise users, education users, creators, and general consumers.

Compared with GitHub login, Google login reaches a broader audience. But it also has more configuration pieces: Google Cloud project, OAuth consent screen, OAuth Client, Authorized redirect URI, scopes, ID Token, verified email, and account linking.

This article follows Google's official identity and OAuth documentation:

• OpenID Connect
• Using OAuth 2.0 for Web Server Applications

Step 1: Create a Google Cloud Project

Before integrating Google login, open Google Cloud Console and create or select a project.

OAuth clients, consent screen, app name, redirect URIs, and secrets all belong to this project.

If your product has development, staging, and production environments, plan how projects and OAuth clients map to environments. Early on, you can create multiple OAuth clients in one project, or use separate projects for separate environments.

The key is not mixing test and production configuration. Callback URLs, secrets, and authorization state become error-prone when environments are mixed.

Step 2: Configure OAuth Consent Screen

Google login shows a consent screen telling users which app is requesting login permission.

You need to configure app name, support email, developer contact, homepage, privacy policy, terms, and related fields.

If you are testing internally, you can use testing status and test users first. If you want to launch publicly, complete the required Google configuration.

The consent screen is not decoration. It affects whether users trust your product. App name, domain, and description should match.

Step 3: Create an OAuth Client ID

Under APIs & Services, open Credentials and create an OAuth client ID.

Choose Web application as the application type. Then configure:

Name: Client name, such as Production Web
Authorized JavaScript origins: Your site origin
Authorized redirect URIs: Your OAuth callback URL

Example:

Authorized JavaScript origins:
https://example.com

Authorized redirect URIs:
https://example.com/api/auth/callback/google

For development:

http://localhost:3000
http://localhost:3000/api/auth/callback/google

Google's docs emphasize that the redirect_uri in the authorization request must exactly match one of the Authorized redirect URIs in Cloud Console, including scheme, case, path, and trailing slash.

Step 4: Save Client ID and Client Secret

After creating the OAuth Client, you receive Client ID and Client Secret.

Like other OAuth platforms:

Client ID: Used to build authorization requests
Client Secret: Server-side only, used to exchange code for token

Store them in environment variables:

GOOGLE_CLIENT_ID=xxx
GOOGLE_CLIENT_SECRET=xxx
GOOGLE_CALLBACK_URL=https://example.com/api/auth/callback/google

Do not put Client Secret in frontend code or public repositories.

Step 5: Build the Authorization URL

Google Web Server flow uses the authorization code flow. When users click “Login with Google,” redirect them to Google's authorization endpoint.

Common parameters include:

client_id
redirect_uri
response_type=code
scope
state
access_type
prompt

Common login scopes:

openid profile email

Google's OpenID Connect docs state that login scopes must start with openid, then include profile, email, or both as needed.

state prevents forgery and correlates request and response. Save it when starting login, then verify it on callback.

Step 6: Handle Callback and Exchange Token

After the user authorizes, Google redirects back to your redirect URI with code and state.

Your server verifies state first, then exchanges code for tokens.

The token response usually includes access token and ID token. For login, ID token is especially important because it contains user identity claims.

The code exchange must happen on the server because it uses Client Secret.

Step 7: Verify ID Token

Google login uses OpenID Connect, so user identity can be represented by an ID Token.

Do not trust an ID Token just because you received it. The server should verify:

Is the signature valid?
Is iss Google?
Does aud equal your Client ID?
Is exp still valid?
Does nonce / state match your flow?

Many mature auth libraries handle these checks. Do not casually decode a JWT and treat it as trusted identity.

Step 8: Use sub to Link Local User

Google's stable user identifier is usually sub. It is better than email as the provider user ID.

A local account linking table can look like:

user_id
provider = google
provider_user_id = sub
provider_email = email
email_verified = true / false
created_at
updated_at

Do not use email as the only unique binding. Email may change or collide with enterprise domains, aliases, or existing accounts.

Using sub as the third-party account identifier is safer.

Step 9: Check Whether Email Is Verified

Google identity information usually includes email and email_verified.

If your product depends on email as an important identity field, confirm email_verified is true. Otherwise, do not treat it as reliable.

If email is not verified or not returned, ask the user to provide an email or complete extra verification.

Email is used for login, notifications, account recovery, payment, and team invitations. Do not assume it is always reliable.

Step 10: Create a Local Session

After Google login succeeds, your system should create its own session or cookie.

Do not use Google access token as your product login state. The access token is for Google APIs. It is not your app session.

If you only use Google for login, you do not need to store the Google access token long term. If you need to access Google Drive, Calendar, or other APIs later, store tokens only when needed and handle refresh, revocation, and encryption.

Common Error Checklist

When Google login fails, check:

Does redirect_uri exactly match Cloud Console?
Did you choose Web application type?
Is OAuth consent screen configured?
Does scope include openid profile email?
Is state saved and verified?
Does code exchange happen on the server?
Is ID Token verified correctly?
Do you link local users by sub?
Do you check email_verified?
Do you create a local session?

The most common issue is redirect_uri_mismatch. When it happens, compare scheme, domain, path, and trailing slash in Cloud Console.

Final Thoughts

Google login has broad reach, but it requires precise configuration and careful identity verification.

A reliable Google login flow should include a clear Cloud project, trustworthy consent screen, exact redirect URI match, minimum scopes, state verification, ID Token validation, sub-based linking, and local session creation.

Next, we enter payment integration: Stripe Integration Tutorial.