Matt Turley, Continuum. Updated November 5, 2026.
For founders whose "Sign in with Google" (or GitHub, Apple, Microsoft) works on localhost and breaks, loops or lands on the wrong page once the app is live.
The provider is rejecting the redirect, or your callback cannot finish the code exchange. The reason is in the URL (look for error and error_description) or the provider console. The usual causes are a redirect URI that does not match exactly, a localhost Site URL left in production, or a client secret that differs between environments.
OAuth is a round trip. Your app sends the user to the provider with a client id and a redirect URI; the provider authenticates them and sends the browser back to that exact URI with a one-time code; your server then exchanges the code for a session using a client secret. A fault at any of those hand-offs ends with the user stuck on a provider error page, back on the login page, or on a blank callback route.
Almost every production failure is a configuration mismatch between the app and the provider, because the two are set up in different consoles and tested separately. Localhost works because localhost is the only URL anyone registered.
If you use Supabase, Clerk, Auth0 or NextAuth, there is a third place to configure as well: the auth service has its own allowed redirect list and its own Site URL.
How to tell The provider shows an error such as "redirect_uri_mismatch". The registered value and the one your app sends differ in scheme, host, path or a trailing slash, or the live domain was never registered at all. Preview deployments are different hosts, so each also needs registering or a wildcard where the provider allows one.
The fix Register the exact production callback URL in the provider console, character for character, and remove the habit of editing it on the fly.
How to tell Login succeeds, then the browser lands on http://localhost:3000. In Supabase, the Site URL defaults to localhost, and redirects to anything outside the allow list fall back to the Site URL.
The fix Set the Site URL to the production domain and add every legitimate callback and preview pattern to the redirect allow list in the auth service settings.
How to tell Only you (or a few named people) can sign in. Others see "Access blocked" or a warning that the app has not completed verification. Google consent screens in testing status allow only listed test users.
The fix Move the consent screen out of testing and complete whatever verification the requested scopes require, or ask only for basic profile and email scopes that do not need review.
How to tell The callback logs "invalid_client" or "invalid_grant". The secret was pasted with a trailing newline, belongs to a different provider app (development versus production), or exists only in the Preview scope.
The fix Set the production client id and secret in the production environment, check them for stray whitespace, and rotate the secret if it was ever pasted into a chat or committed to a repository.
How to tell Errors mention "invalid state" or a missing code verifier. Login starts on one host (the apex domain) and the callback arrives on another (www), so the cookie set at the start is not sent back. A strict cookie setting can cause the same.
The fix Serve the whole login flow from one canonical host, redirect the other to it, and keep cookie attributes consistent between the route that starts login and the route that finishes it.
How to tell The user comes back to /login?code=... with the code still in the URL, or the callback route returns 404 or 500. The route is missing, was renamed, is protected by auth middleware, or throws before creating the session.
The fix Make sure the callback route exists at the registered path, exclude it from auth middleware, and read the function log for the exchange call. Create the session before redirecting anywhere.
error and error_description parameter usually names the problem outright.If the provider error says redirect_uri_mismatch, you almost certainly need five minutes in a settings page, not an engineer. The same goes for a Site URL left on localhost. Pay for help when the redirects look right and sign-in still fails, or when auth, middleware and cookies are tangled together.
Auth is the part of an AI-built app most likely to look right and be wrong for strangers. A Ship Check includes a security and data read of the login flow, not just whether it loads.
Ship Check, $299: A senior engineer reads your codebase and sends a written verdict (fine, fixable or rewrite), what will break first, a security and data read, and a costed plan, within 48 hours of repo access or it is free. It has a 7-day money-back and is credited against a Ship Fix. Or: Book a call.