Fixing Google OAuth 2.0 error 400: redirect_uri_mismatch troubleshooting guide

If you have ever implemented Google social authentication in a web application, there is a good chance you have run into this error screen:

Error 400: redirect_uri_mismatch
You can't sign in to this app because it doesn't comply with Google's OAuth 2.0 policy.
If you're the app developer, register the redirect URI in the Google Cloud Console.
Request details: redirect_uri=https://app.domain.com flowName=GeneralOAuthFlow

At first glance, this message can seem alarming when pushing a project to production. However, Google's OAuth 2.0 implementation is deliberately strict: the redirect_uri parameter is a core security check preventing authorization codes and tokens from being intercepted by untrusted domains.

Here is what happens behind the scenes and how to diagnose and resolve the issue directly in Google Cloud Platform (GCP).

What happens under the hood?#

When a user clicks "Sign in with Google", the browser sends a request to Google's authorization endpoints (accounts.google.com/o/oauth2/v2/auth) containing key parameters:

• client_id: Your application's public identifier.
• response_type: Typically code in the standard authorization code flow.
• scope: The permissions requested (such as email and basic profile).
• redirect_uri: The exact destination where Google must send the authorization code once the user consents.

When Google receives this request, it compares the received redirect_uri against the list of Authorized redirect URIs configured in your GCP credentials.

This comparison is an exact character-by-character match. If there is a single difference in protocol, trailing slash, or subdomain, Google halts the flow immediately with an HTTP 400 Bad Request before displaying the account selection screen.

The 4 most common causes of the mismatch#

In real-world applications, this error is almost always caused by one of these four scenarios:

1. Protocol mismatch (http:// vs https://)#

Local development uses http://localhost, while production environments enforce SSL (https://). If your backend sits behind a reverse proxy (such as Nginx, Traefik, or Cloudflare) that fails to forward the X-Forwarded-Proto header, the app may build the callback URL using http://, triggering a mismatch against the https:// entry in the console.

2. The trailing slash trap#

For Google's validator, these two addresses are distinct strings:

• https://app.domain.com/callback
• https://app.domain.com/callback/

If your code submits the route without a trailing slash while GCP has it saved with one (or vice versa), the match fails.

3. www subdomain vs apex domain#

https://www.domain.com and https://domain.com are treated as separate origins. If your application accepts traffic on both domains without a mandatory 301 canonical redirect, both variants must be explicitly added to the authorized list.

4. Environment transitions (localhost to production)#

During local development, http://localhost:3000/api/auth/callback/google is typically registered. When moving to production on a custom domain, forgetting to register the production URL in the GCP credential is the single most frequent cause of this error.

Diagnosing the real-world error#

Google provides the exact string that failed under the error details:

Request details: redirect_uri=https://app.domain.com flowName=GeneralOAuthFlow

In this case, the callback URL sent by the application was https://app.domain.com. The failure occurred because that exact string was missing from the authorized list of the matching client_id.

Step-by-step fix in Google cloud console#

To register the missing URI:

1. Open Google Cloud Console:

Visit console.cloud.google.com and sign in with the account managing your project.

1. Go to Credentials:

In the left navigation menu, open APIs & Services > Credentials.

1. Edit the OAuth 2.0 Client ID:

Under OAuth 2.0 Client IDs, click the credential your web application uses.

1. Add the Authorized Redirect URI:

Scroll down to Authorized redirect URIs and click + Add URI. Enter the exact URL copied from the error details:

https://app.domain.com

(If your framework requires a specific path, such as /api/auth/callback/google or /auth/google/callback, enter the full endpoint).

1. Save changes:

Click Save at the bottom of the page.

What to verify before going live#

After saving your new URI in GCP, changes propagate across Google's edge within seconds to a few minutes. Retrying the login flow in your browser will now render the Google account selection prompt properly.

The key takeaway when dealing with OAuth 2.0 is that strings must match verbatim. Check the exact literal value displayed in the redirect_uri field of the error screen and ensure that exact string is saved in your GCP credentials.

See also

Development Upgrading Vite in Laravel: from kernel inotify to manifest.json

Cybersecurity Fast javascript security triage: hunting backdoors and vulnerabilities with grep

Development How to integrate IndexNow: instant search engine indexing for websites, SaaS, and APIs

This post is licensed under CC BY-NC.