"Access blocked: This app's request is invalid" - find the real error and fix it
"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
- 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 asredirect_uri=https://example.com/auth/callback flowName=GeneralOAuthFlow(example report). Thatredirect_urivalue is exactly what your app sent. - 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));
- 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_idyou 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
codeandstatequery parameters (server flows) or your SDK returns a signed-in user. - Run the URL snippet above again: the
client_id,redirect_uriandscopevalues match what is registered on the client.
Related problems
Error 400: redirect_uri_mismatchafter moving to a custom domain: redirect_uri_mismatchError 400: invalid_requestwith "Missing required parameter": Error 400: invalid_request403 access_deniedfor apps in Testing: App has not completed Google verification
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
- Understand & fix error codes - Google Account Help
- Using OAuth 2.0 for Web Server Applications - Google for Developers
- OAuth 2.0 for Client-side Web Applications - Google for Developers
- Manage OAuth Clients - Google Cloud Platform Console Help
- Manage App Audience - Google Cloud Platform Console Help
- Best practices for using signInWithRedirect on browsers that block third-party storage access - Firebase
- JOSM ticket #24716 (example of the error screen and request details)
- 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 27 Oct 2026. Spotted something out of date? Tell us.
Related guides
- "Error 400: invalid_request" on Google sign-in: read the details and fix the cause
- "Access blocked: app has not completed the Google verification process" - why and how to fix it
- Google OAuth consent screen: setup, Internal vs External, and why it isn't showing
- Sign in with Google button or One Tap not showing: how to fix it