OAuth login broke after a domain change: redirect_uri_mismatch
"Sign in with Google/GitHub" stopped working right after moving to a custom domain (or adding www, or switching to https). The provider shows redirect_uri_mismatch, or users bounce back logged out.
- Supabase
- Bubble
- Any stack
- Auth & login
- DNS & SSL
Root cause, in plain English
OAuth providers compare your app's callback URL character-for-character against the allowlist registered in their console — scheme, host, and path all must match. Moving from a staging URL to a custom domain changes that callback, so the provider now refuses a redirect it has never been told about. Auth platforms add a second layer: Supabase's Site URL and redirect allowlist must also name the new domain, or users return to the old one.
How to fix it
Read the error parameter on the provider's failure page — it names the exact redirect URI your app sent. Copy it; that's the string you need to register.
In the provider console (Google Cloud OAuth credentials, GitHub OAuth app settings…), add the new callback URL exactly: correct scheme (https), correct host (apex and www if you serve both), correct path.
If an auth platform sits in the middle, update its config too: on Supabase set Site URL to the new domain and add it to Additional Redirect URLs — the provider callback may still be your project's supabase.co URL, which stays unchanged.
Hunt down hardcoded old-domain URLs in your app's environment variables and OAuth client setup; a stale redirect_to parameter re-breaks the flow after everything else is right.
Re-test in a private window for each entry point: apex, www, and any old domain that should now redirect.
Go deeper: copy the open-source health-check recipe.
How Nightlamp detects this automatically
- Browser journey
- HTTP status
- SSL expiry
A browser_journey runs the real sign-in flow in a browser and alerts when the redirect chain stops landing users in a session — exactly how this break presents. An http_status check watches the callback endpoint for error responses, and an ssl monitor confirms the new domain's certificate is valid, since OAuth providers refuse redirects to hosts with broken HTTPS.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Why does login work on www but not on the bare domain?
- To an OAuth provider, www.example.com and example.com are different hosts, and each callback URL must be registered separately. Either register both or redirect one to the other at the edge before the login flow starts.
- I updated the provider console — why is it still failing?
- Provider-side changes can take a few minutes to propagate, browsers cache redirects aggressively, and there's often a second allowlist in your auth platform (e.g. Supabase's redirect URLs). Re-test in a fresh private window and check every layer the redirect passes through.
- Users log in but land back on the old domain. What's that?
- That's usually the auth platform's Site URL (the default post-login destination) still pointing at the old domain, not an OAuth mismatch. Update it and any redirect_to values your app passes during sign-in.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.