"Access blocked: This app's request is invalid" - find the real error and fix it

Updated Oct 27, 2026 · Pewterkit Guides

"Access blocked: This app's request is invalid" is Google's generic screen for a sign-in request it refused before showing the account chooser. The real reason is the error code hidden behind the "see error details" link (most often Error 400: redirect_uri_mismatch), so open it first and fix that specific cause.

What the screen means

Google's OAuth server checks every authorization request (client ID, redirect URI, origin, parameters, browser) before it lets anyone sign in. When a check fails, it stops and shows a block page instead of redirecting back to your app. For invalid_request and redirect_uri_mismatch, Google says only the app's developer can fix the error (Google Account Help).

The page typically reads:

Access blocked: This app's request is invalid
You can't sign in because this app sent an invalid request.
If you are a developer of this app, see error details.
Error 400: redirect_uri_mismatch

The headline wording varies. The same block page can say "Access blocked: Authorization Error" with Error 400: invalid_request underneath (example report). Treat the headline as a label and the error code as the diagnosis.

How to see the real error

  1. Click "see error details". The link under the message expands the code (for example Error 400: redirect_uri_mismatch) and often a "Request details" block such as redirect_uri=https://example.com/auth/callback flowName=GeneralOAuthFlow (example report). That redirect_uri value is exactly what your app sent.
  2. Capture the full authorization URL. Start sign-in again with your browser's developer tools open (Network tab, "Preserve log" on) and copy the request to accounts.google.com/o/oauth2/v2/auth (or the address bar URL of the error page). Paste this into the developer tools console to list every parameter your app sent:

js // Paste the accounts.google.com URL when prompted const u = new URL(prompt("Paste the Google authorization URL")); console.table(Object.fromEntries(u.searchParams));

  1. Compare against your OAuth client. Open the Google Cloud console, go to Google Auth Platform, then Clients (as of Oct 2026), and open the client whose ID matches the client_id you just printed. Most cases of this screen come down to a difference between what the request contains and what that client allows.

Fix it by error code

Error 400: redirect_uri_mismatch (most common)

The redirect_uri in the request does not exactly match one of the client's Authorized redirect URIs. Scheme, host, port, path, case and trailing slash all count (Google OAuth 2.0 for web server apps). Copy the value from "Request details" and add it, character for character, to the client's Authorized redirect URIs (as of Oct 2026: Google Auth Platform > Clients > your web client > Authorized redirect URIs > Add URI > Save).

For Firebase Auth the redirect URI is your authDomain plus /__/auth/handler, for example https://<your-auth-domain>/__/auth/handler, so changing authDomain means adding a new URI (Firebase redirect best practices). The full walkthrough for every framework is in the redirect_uri_mismatch guide; for local development see redirect_uri_mismatch on localhost, and for Firebase's handler path see the Firebase auth handler guide.

Error 400: invalid_request

The request is malformed, is missing a required parameter, or uses an authorization method Google does not support (Google OAuth 2.0 for web server apps). The line under the code names the problem, for example "Missing required parameter: client_id". Typical causes are an empty environment variable in production, the retired out-of-band (urn:ietf:wg:oauth:2.0:oob) redirect (which Google notes can also surface as redirect_uri_mismatch), or a custom URI scheme redirect. Each cause and its fix is covered in Error 400: invalid_request.

Error 400: origin_mismatch

Used by browser-side (JavaScript) flows. The scheme, domain or port of the page that started sign-in is not listed in the client's Authorized JavaScript origins (Google OAuth 2.0 for client-side web apps). Add the exact origin, such as https://app.example.com. Origins must use HTTPS (localhost is exempt) and cannot contain a path, query, fragment or wildcard (Manage OAuth Clients).

Correct:   https://app.example.com
Correct:   http://localhost:5173
Rejected:  https://app.example.com/        (trailing path)
Rejected:  https://*.example.com           (wildcard)

Error 401: invalid_client or deleted_client

invalid_client means the client secret is incorrect, so Google tells you to review the client ID and secret used for the request; deleted_client means the OAuth client was deleted, manually or automatically for being unused. Deleted clients can be restored within 30 days (Google OAuth 2.0 for web server apps). Check that production uses the same client ID you configured, and that the client still exists on the Clients page.

Error 403: disallowed_useragent

The sign-in page opened inside an embedded web view, which Google's policies do not allow (Google OAuth 2.0 for web server apps). Open the authorization URL in the system browser, or use Google Sign-In for iOS or AppAuth on mobile. Users can sometimes work around it by signing in from a regular browser instead of the app (Google Account Help).

Error 403: org_internal

The OAuth app's audience is set to Internal, so only accounts in its Google Cloud organization can sign in (Manage App Audience). Sign in with an organization account, or switch the audience to External.

If the screen instead says the app "has not completed the Google verification process", that is a different block (403 access_denied) covered in App has not completed Google verification.

Wait for the change to apply

Edits to redirect URIs and JavaScript origins are not instant. Google states it may take 5 minutes to a few hours for changes to these settings to take effect (Manage OAuth Clients). Retest after a few minutes before changing anything else.

How to confirm it worked

  • Start sign-in in a private window. Google shows the account chooser or consent screen instead of the block page.
  • After you choose an account, your callback URL loads with code and state query parameters (server flows) or your SDK returns a signed-in user.
  • Run the URL snippet above again: the client_id, redirect_uri and scope values match what is registered on the client.

FAQ

Can a user fix "Access blocked: This app's request is invalid"?

Usually not. Google's help pages say only the app developer can fix invalid_request and redirect_uri_mismatch errors; the user can report the error to the developer (Google Account Help).

Where do I find the actual error code?

Click "If you are a developer of this app, see error details" on the block page. It reveals the code, such as Error 400: redirect_uri_mismatch, and often the redirect_uri your app sent.

I added the redirect URI and still see the error. Why?

Changes can take 5 minutes to a few hours to apply (Manage OAuth Clients). Also confirm you edited the client whose ID appears in the request, and that the URI matches exactly, including http versus https and any trailing slash.

Does Google allow wildcards in redirect URIs?

No. Redirect URIs cannot contain wildcard characters, fragments, path traversal or open redirects, and must use HTTPS except for localhost (Google OAuth 2.0 for web server apps).

Why does the request work locally but not in production?

Production usually sends a different redirect_uri (your real domain) or a different client_id from environment variables. Register the production redirect URI and origin on the same client, or check that production loads the right client ID.

Sources

  1. Understand & fix error codes - Google Account Help
  2. Using OAuth 2.0 for Web Server Applications - Google for Developers
  3. OAuth 2.0 for Client-side Web Applications - Google for Developers
  4. Manage OAuth Clients - Google Cloud Platform Console Help
  5. Manage App Audience - Google Cloud Platform Console Help
  6. Best practices for using signInWithRedirect on browsers that block third-party storage access - Firebase
  7. JOSM ticket #24716 (example of the error screen and request details)
  8. Zammad community: Google OAuth Missing required parameter: client_id (example screen)

How this page was made: drafted with AI from the sources listed, reviewed by Pewterkit. Docs checked Oct 27, 2026. Spotted something out of date? Tell us.

Related guides