"Access blocked: app has not completed the Google verification process" - why and how to fix it

What the error means

The full screen reads "Access blocked: has not completed the Google verification process" with Error 403: access_denied underneath (example report). Google's own help page describes 403 access_denied as the user not being authorized, and lists "the app is in test mode and the developer hasn't added you as a test user" as a common cause (Google Account Help).

Despite the wording, this is not a verdict on a verification request you submitted. It is the Testing-mode gate: while the publishing status is Testing, the account signing in is not allowed through.

Why it happens

Every External OAuth app has a publishing status (Manage App Audience):

Testing has two more rules worth knowing (Manage App Audience):

• Authorizations by test users expire seven days after consent, including refresh tokens. A backend that "stops working after a week" in Testing is usually this.
• Google's audience documentation says that if an app requests only name, email address and profile (openid, email, profile), its users don't need to be on the test user list and their authorizations don't expire after seven days. Request any other scope (Gmail, Drive, Calendar, Sheets...) and the test user list and seven-day expiry apply.

Don't rely on that exception to diagnose this block. If you see it, the dependable fixes are the ones below: add the account as a test user, or publish the app to In production. Separately, check whether your code or library is quietly asking for extra scopes.

Fix 1: add the account as a test user (fastest)

Use this while you are still building or for a small private tool. As of Oct 2026:

1. Open the Google Cloud console and select the project that owns your OAuth client.
2. Go to Google Auth Platform > Audience.
3. Under Test users, click Add users, enter the Google account email (for example you@gmail.com), and click Save (Configure the OAuth consent screen).
4. Sign in again with that exact account.

Each added test user counts toward the project's 100 test user limit (Manage App Audience).

Fix 2: request only the scopes you use

Do this alongside Fix 1 or Fix 3, not instead of them. If your app only needs to know who the user is, limit the request to openid email profile. As of Oct 2026, open Google Auth Platform > Data Access and remove scopes you do not use (Configure the OAuth consent screen). Then remove them from your code too, because the request itself decides what Google checks. For example, with the Firebase Web SDK, drop extra addScope calls (Firebase: Authenticate using Google):

import { getAuth, GoogleAuthProvider, signInWithPopup } from "firebase/auth";

const provider = new GoogleAuthProvider();
// Only add scopes your app really uses. Remove lines like this one:
// provider.addScope("https://www.googleapis.com/auth/drive.readonly");
await signInWithPopup(getAuth(), provider);

Keeping the console list and the code in step also avoids the separate "unverified app" warning, which Google shows when the scopes in your code don't match the consent screen configuration (Unverified apps).

Fix 3: publish the app to In production

When real users need access, as of Oct 2026 go to Google Auth Platform > Audience and click Publish app (Manage App Audience). What happens next depends on your scopes:

Until a sensitive or restricted scope request is approved, users see an "unverified app" screen and the app is capped at 100 new users in total (Unverified apps).

Fix 4: use Internal if every user is in your organization

If everyone signing in belongs to your Google Workspace or Cloud Identity organization, set the audience to Internal. Internal apps are not subject to the unverified app screen or the 100-user cap, but accounts outside the organization get an org_internal error (When is verification not needed, Manage App Audience). Internal requires a Google Cloud organization, so it is not available to a personal Gmail-only project.

When verification is not needed

Google lists these cases as exempt from mandatory verification (When is verification not needed):

• Personal use with fewer than 100 users.
• Apps in development, testing or staging (the unverified app screen and 100-user cap still apply).
• Apps that use a service account to access only their own data.
• Internal apps used only within your Workspace or Cloud Identity organization.
• Apps an administrator has marked as trusted or installed from the Marketplace for their domain.

How long does Google verification take?

Google's published estimates (Frequently Asked Questions):

Google notes these are estimates, not commitments, and that they vary with how quickly you answer its questions. To avoid round trips, have these ready before you submit (Verification requirements, Unverified apps):

• A homepage that describes the app (it cannot be only a login page) and a privacy policy, both on a domain you own.
• That domain confirmed in Google Search Console by a project Owner or Editor.
• Accurate app name, logo and support email.
• For sensitive or restricted scopes, a demo video showing the full OAuth grant flow and a justification for each scope.

After approval, changing the product name, adding scopes, redirect URIs or JavaScript origins can require verification again (Unverified apps).

How to confirm it worked

• Sign in with the affected account in a private window. You see the account chooser and consent screen instead of the block.
• On Audience, the publishing status and test user list show what you expect (as of Oct 2026).
• If you published the app, an account that is not on the test user list can now sign in.

Related problems

• Your app name shows as a domain on the Google screen: Google sign-in app name
• Setting up the screen from scratch: Google OAuth consent screen
• "Access blocked: This app's request is invalid" (an Error 400, not 403): Access blocked: This app's request is invalid
• Supabase projects: Supabase Google OAuth setup