Fix Error 400: redirect_uri_mismatch in OAuth and OpenID Connect Logins

You click “Sign in with Google” or another provider, and instead of logging in, you’re met with Error 400: redirect_uri_mismatch. Annoying, right? This error stops you from accessing apps, breaks login flows, and interrupts your work. In this guide, we’ll explain what it means, why it happens, the most common causes, how to fix it, and tips to prevent it in the future.

What is Error 400: redirect_uri_mismatch?

Error 400: redirect_uri_mismatch appears when the OAuth or OpenID Connect sign-in process fails. In plain language, it means the login provider (like Google, Microsoft, GitHub, or Facebook) was expecting your app to send users back to a specific URL but the app sent something different. Since the callback URL doesn’t match what’s registered, the login request gets blocked.

You’ll usually see this error in your browser during login, right after clicking a provider button. Google shows it on a white error screen, while other identity platforms like Okta, Auth0, or Microsoft display similar mismatch messages. It can happen in web apps, mobile deep links, or even local development setups when the callback isn’t set up right.

Common Causes of Error 400: redirect_uri_mismatch

This error has a handful of frequent triggers:

• HTTPS vs HTTP or wrong port number in the callback URL.
• A missing or extra trailing slash in the redirect path.
• Wrong domain or subdomain (using staging vs production).
• Redirect URI not added to Authorized redirect URIs in the provider console.
• Environment variable drift (.env files, secrets) not matching the deployed URL.
• Double redirects through reverse proxy or CDN changing the scheme or host.
• URL encoding problems or case sensitivity in paths.

How to Fix Error 400: redirect_uri_mismatch?

The fixes for this error depend on aligning the redirect_uri in your app with the one registered in the identity provider’s settings. The key is: they must match exactly — same domain, path, scheme, and port. Follow these solutions one by one.

Fix #1 Compare the Redirect URIs

Start by checking what your app is actually sending.

• Open browser devtools → Network tab.
• Find the OAuth request to the provider.
• Copy the redirect_uri parameter from the URL.
• Compare it against the callback URL listed in your provider’s console.
  If they’re not identical, that’s the root cause.

Fix #2 Update Authorized Redirect URIs in the Provider Console

If the app is using the correct callback but the provider doesn’t recognize it, add it to the console.
Here are the steps you can follow:

1. Sign in to your provider’s admin console (Google, Microsoft, GitHub, Okta, etc.).
2. Open the app or OAuth client registration.
3. Find “Authorized redirect URIs” or “Allowed callback URLs.”
4. Paste the exact redirect_uri from your app, including scheme (https), domain, path, and port if needed.
5. Save changes.
6. Restart your app and test the login again.

Fix #3 Align Environment Variables

Many apps rely on env variables for base URLs. If these drift, the callback breaks.
Steps:

1. Open your .env or secrets manager.
2. Look for variables like BASE_URL, NEXTAUTH_URL, CALLBACK_URL.
3. Match them to the actual deployed domain and callback path.
4. Remove wrong ports or extra slashes.
5. Restart and redeploy your app.

Fix #4 Normalize Proxy or CDN Settings

If your app runs behind a proxy, CDN, or load balancer, headers can change the URL.

• Ensure X-Forwarded-Proto and X-Forwarded-Host headers are passed correctly.
• Configure your app or framework to trust proxy headers.
• Force HTTPS at the proxy level so redirect_uris are consistent.
  This prevents mismatch between the public domain and internal routing.

Fix #5 Handle Trailing Slash and Case Sensitivity

Some providers treat /callback and /callback/ as different. Others treat /App and /app differently.
If allowed, add both variants to the provider console. If not, stick to one consistent format in both your app and provider settings.

Fix #6 Check Framework-Specific Defaults

Different frameworks come with default callback paths.
Here are common examples:

• NextAuth.js → /api/auth/callback/[provider]
• Passport.js → /auth/[provider]/callback
• Django-allauth → /accounts/[provider]/login/callback/
• Spring Security → /login/oauth2/code/[provider]
  Make sure the path your framework uses is the same one registered in the provider’s settings.

Fix #7 Fix Encoding or Special Characters

The redirect_uri must be URL-encoded properly. For example:

• https://myapp.com/callback?param=value
  should be encoded as
• https%3A%2F%2Fmyapp.com%2Fcallback%3Fparam%3Dvalue
  Check logs and browser requests to confirm. If you see unencoded characters, fix your app’s auth library or configuration.

Fix #8 Double-Check Provider Quick Settings

For the most common identity providers:

• Google Cloud Console → APIs & Services → Credentials → OAuth Client → Authorized Redirect URIs.
• Microsoft Entra (Azure AD) → App Registrations → Redirect URIs.
• GitHub → Developer Settings → OAuth Apps → Authorization callback URL.
  Paste the correct URL and save.

Fix #9 Mobile Deep Links or Custom Schemes

If you’re working with a mobile app:

1. Confirm your app claims the custom URI scheme (e.g., myapp://callback).
2. Check iOS Associated Domains or Android intent filters.
3. Add that exact scheme to the provider console.
4. Rebuild and test on device.

Fix #10 Use Logs and Test Accounts

If nothing works, create a test account and capture full network logs (HAR files). Look for silent rewrites, redirects, or case changes. This shows exactly where the mismatch is happening.

Prevention Tips to Avoid Error 400: redirect_uri_mismatch?

A few simple habits can save you from seeing this error again:

• Keep a single source of truth for your app’s base URL and callback path.
• Store redirect URIs in config or environment files, not hard-coded.
• Always use HTTPS for production logins.
• Add all needed environments (dev, staging, production) to the provider’s redirect settings.
• Document callback conventions so team members don’t introduce mismatches.
• Monitor login failures with logs and alerts.
• Test sign-in flows after every major deployment.

Conclusion

Error 400: redirect_uri_mismatch means your app’s callback URL didn’t match what the identity provider expected. It usually comes down to a small mismatch in domain, path, scheme, or environment settings.

By making sure URLs match exactly and keeping your configs consistent, you can prevent this error from blocking sign-ins. If it still happens, the detailed Fix section (once completed) will walk through the exact steps to repair it.