Introduction

An app migration can move the site successfully while OAuth login still sends users back to the old domain. The homepage, API, and static assets may all load from the new environment, but authentication fails because the identity provider or the application itself still uses a callback URL that references the previous host.

Treat this as a redirect-URI mismatch instead of a general login outage. Start by capturing the exact redirect_uri value used during sign-in, because OAuth providers validate callback URLs strictly and one stale hostname, scheme, or path can keep authentication tied to the old domain after the rest of the migration is finished.

Symptoms

  • Users are redirected to the old domain during OAuth or single sign-on login
  • The provider returns redirect_uri_mismatch, invalid_redirect_uri, or a similar callback error
  • Login starts correctly, but the callback fails after the identity provider hands the user back
  • The new site works until Google, Microsoft, GitHub, or another OAuth login flow begins
  • One environment or client application works while another still uses the old callback domain
  • The issue started after an app migration, domain move, or authentication configuration change

Common Causes

  • The registered OAuth redirect URI in the identity provider still points to the old domain
  • The application still sends an old redirect_uri value from environment variables or hardcoded configuration
  • Multiple OAuth applications or environments exist, and the wrong client ID is being used in production
  • A reverse proxy or framework still builds callback URLs from stale host or base URL settings
  • Cached or copied authentication configuration survived the migration to the new app environment
  • Validation focused on page availability and missed the full OAuth callback flow

Step-by-Step Fix

  1. Reproduce the login failure and capture the exact redirect_uri value sent during the OAuth request, because you need the real callback URL before deciding whether the provider or the app is wrong.
  2. Compare that redirect_uri with the intended production domain, scheme, and callback path, because even a small mismatch in hostname, HTTPS, or trailing path can break the flow.
  3. Check the OAuth provider configuration and review every allowed redirect URI for the affected application, because one stale callback entry often remains after a domain migration.
  4. Update the registered redirect URI to the new domain and remove the old entry only when the cutover is confirmed, because temporary overlap may be needed during a controlled migration window.
  5. Review the application environment variables, auth settings, and base URL configuration, because many apps keep generating the old redirect_uri even after the provider console has been updated.
  6. Confirm the production site is using the correct client ID and OAuth application, because the wrong environment can silently point users to a provider configuration that still references the old domain.
  7. Check reverse proxy, load balancer, or framework host-header handling if the callback URL is generated dynamically, because stale host or HTTPS detection can rebuild the old domain even with correct provider settings.
  8. Test the full login flow from a clean browser session and confirm the callback lands on the new domain without errors, because one corrected setting does not prove every auth path now uses the right redirect URI.
  9. Document the final redirect URIs, client IDs, and migration-specific auth settings for each environment, because OAuth callback mismatches often return during future domain moves when this inventory is missing.