Google Cloud OAuth Consent Screen + OAuth Client ID (2026 New UI)

[!NOTE]
TL;DR: 2025–2026 Google Cloud Console was reorganized into the Google Auth Platform (Branding / Audience / Data Access / Clients), and the path to set up an OAuth consent screen changed completely. This guide walks from a fresh project to a Web Client ID/Secret in 7 steps, ~10 minutes. The two things that actually matter: picking [External] in the wizard and getting the redirect URI exactly right.

Why this guide exists

• Most existing English guides still describe the old UI and send readers chasing menus that no longer exist.
• The new UI starts with a "Get started" wizard — a single page with 4 stepper sections, not the old multi-screen flow.
• Pick External vs. Internal wrong and a regular web app will not work. The wizard does not let you change it later — you'd need a fresh project.

Prerequisites

• A Google account
• Access to a GCP project (or create one in step 01)
• Billing not required — OAuth consent screen + Client ID setup are free

---

Step 01 — Create a new GCP project

Start here: console.cloud.google.com/projectcreate

From the top-left project selector → "New project", or open the URL directly. Pick a recognizable name. The project ID is globally unique, so a numeric suffix may be appended automatically. Linking a billing account is NOT required for OAuth consent screen setup — skip the prompt if it appears.

Don't forget to switch to the new project from the selector after creating it. Otherwise the next steps will configure OAuth on a different project.

Step 02 — Open the OAuth consent screen → [Get started]

Start here: console.cloud.google.com/auth/branding?project=YOUR_PROJECT_ID

A fresh project shows the "Google Auth Platform not configured yet" notice. Click [Get started] at the bottom right to enter the 4-step wizard.

Three ways to land here (any of them works):

• Left hamburger menu → APIs & Services → OAuth consent screen
• Top search bar → type OAuth → click the result
• Open the URL above directly

Step 03 — Pick [External] in the wizard (most common mistake)

Start here: console.cloud.google.com/auth/overview/create?project=YOUR_PROJECT_ID

The wizard is a single page with 4 stepper sections (1 → 2 → 3 → 4):

1. App Information — App name (shown on the consent screen), User support email (dropdown of your Google accounts)
2. Audience (User Type) — ⚠ the only real decision
3. Contact Information — Email Google uses for policy/notification updates
4. Finish — Accept the policy → [Create]

External vs. Internal — pick once, can't change later (without a fresh project):

Option	Who can sign in?	When to pick?
Internal	Only accounts in the same Google Workspace organization	Internal tools (org account required)
External	Anyone with a Google Account	Public web apps (starts in test mode)

For a typical web app, always pick [External]. External starts in "test mode" — only test users you add in step 04 can sign in until you publish the app.

Step 04 — [Audience] tab — add test users

Start here: console.cloud.google.com/auth/audience?project=YOUR_PROJECT_ID

An External-type OAuth app starts in "Testing" mode. Only Google accounts on the [Test users] list can sign in — everyone else hits an access_blocked error (the actual face of "Error 403: access_denied" you've probably seen elsewhere).

Click [Add users] and register your own + teammate/QA emails (up to 100). Effective immediately.

After publishing to production anyone can sign in, but:

• Non-sensitive scopes (openid/email/profile) → publish freely
• Sensitive scopes (Drive/Gmail/Calendar etc.) → Google verification process (weeks, security review)

Step 05 — [Data access] tab — add OAuth scopes

Start here: console.cloud.google.com/auth/scopes?project=YOUR_PROJECT_ID

Define the scopes (permissions) shown to users on the consent screen.

For typical Google Sign-In, three are enough (all non-sensitive):

• openid
• .../auth/userinfo.email
• .../auth/userinfo.profile

Click [Add or remove scopes] → check the three in the right panel → [Update].

Scope category	What it accesses	Google verification
Non-sensitive	Basic identity (email, profile)	Not required
Sensitive	Some Drive/Gmail/Calendar	Required
Restricted	Full Gmail/Drive	Required + security assessment

Step 06 — Web client + Authorized redirect URIs

Start here: console.cloud.google.com/auth/clients/create?project=YOUR_PROJECT_ID

[Clients] tab → [Create Client] to get here.

Form fields:

• Application type: Web application for any browser-initiated OAuth flow (including BE servers exchanging tokens)
• Name: just a label (e.g., myapp-web-prod, myapp-web-dev)
• Authorized JavaScript origins: only needed for SPAs (browser-only token retrieval). Leave blank if your BE handles it
• Authorized redirect URIs: the exact callback URL ⚠

A single character mismatch in the redirect URI yields redirect_uri_mismatch. Common slip-ups:

• http:// vs. https://
• Trailing slash (/callback vs. /callback/)
• Port (:3000 present or not)
• Missing dev/staging/prod URIs

http://localhost:3000/... works for local dev. Multiple URIs allowed on the same client.

Then [Create].

Step 07 — Save Client ID + Secret (Secret won't be shown again)

Right after [Create], the OAuth client created dialog appears.

Credential	Public OK?
Client ID (123-abc.apps.googleusercontent.com)	✓ Public OK (the identifier visible in browsers)
Client Secret (GOCSPX-...)	✗ Never expose

Once the dialog closes, the Secret is never shown again. You'd need to issue a new secret or recreate the client.

Click [Download JSON] and:

1. Move it to .env or a password manager (1Password, Bitwarden, etc.) immediately
2. Never commit to Git — add *.env, client_secret*.json to .gitignore
3. Delete the downloaded JSON file from disk after saving

If exposed, rotate immediately: [Clients] tab → the client → "Add/Revoke secret" to issue a new one and expire the old.

Common mistakes

1. Picked Internal → web app only accepts org accounts. You'd need a fresh project (External isn't reachable later).
2. Forgot to register test users → you can sign in but teammates/QA hit access_blocked.
3. Redirect URI off by a character → redirect_uri_mismatch. Register every environment URI.
4. Hardcoded Client Secret in source instead of .env → exposed on Git push. Use a pre-commit hook (gitleaks, detect-secrets) to block it.
5. Adding sensitive scopes and trying to publish without verification → Google verification required. Ship the first version with non-sensitive scopes (openid/email/profile) only.
6. Navigating away mid-wizard → wizard ends in an incomplete state. Start over from step 02.
7. Picked iOS/Android/Desktop instead of Web Application → wrong OAuth flow, won't fit your BE server code.

References

• Google Identity — Official docs
• Web server OAuth flow
• OAuth verification (sensitive scopes)
• Google Cloud Console (Auth Platform)

---

Written against the 2026-04-18 Google Cloud Console UI. The UI may shift again — substitute your own project ID into the URLs above when following along.