Authentication and deployment
Google sign-in works on localhost but fails on my production domain
Google sign-in works on localhost. You deploy the same app, click the same button, and Firebase responds with auth/unauthorized-domain.
It's tempting to start changing the login code because that's the part you can see. I'd put the deployed hostname beside the Firebase configuration first. The code may be doing exactly what it did locally, with a domain the project hasn't been configured to accept.
The error tells you which settings to open
| Symptom | Where I'd look |
|---|---|
auth/unauthorized-domain | Authorized domains in Firebase Authentication. |
Google shows redirect_uri_mismatch | The OAuth client's callback URL and the app's configured authDomain. |
| A popup error appears before Google opens | The popup call and the browser's popup behavior. |
| A redirect returns without a signed-in user | Redirect result handling and browser storage behavior. |
| Google finishes, then your API returns 401 or 403 | The backend request, token and application origin. |
Keep the error code and the hostname together while debugging. "Login is broken" sends you searching through the whole application; auth/unauthorized-domain on app.example.com gives you somewhere useful to start.
Add the production host to the right Firebase project
Open Authentication settings in the project used by the deployed web app, then check Authorized domains. Add the hostname where people are signing in, such as app.example.com. Check the address bar: example.com, www.example.com and app.example.com are different hosts.
If that host is already listed, compare the deployed Firebase configuration with the project you just opened. A production page can still contain a frontend bundle built with staging settings. Changing the environment file on your laptop won't update that bundle.
The same check explains preview-only failures. Your main application domain may be configured correctly while the generated preview hostname is absent. Firebase's authentication troubleshooting guide covers the domain error and the API-key configuration to inspect next.
Check where Google sends the user back
Firebase's authDomain is the domain that serves its authentication helper. With the standard project domain, the Google callback looks like this:
https://YOUR_PROJECT.firebaseapp.com/__/auth/handler
Compare that complete URL with the OAuth client's authorized redirect URIs. The /__/auth/handler part matters. Entering the application's homepage gives Google a different destination from the one Firebase requests.
A custom authentication domain changes the hostname in that callback. Firebase's Google sign-in guide walks through the Hosting setup, authorized domain and OAuth callback together. Updating authDomain in JavaScript is only one part of that setup; the helper also needs to be served at the new address.
I find it useful to line these up before editing anything:
Application: https://app.example.com
Firebase project: YOUR_PROJECT
authDomain: YOUR_PROJECT.firebaseapp.com
Google callback: https://YOUR_PROJECT.firebaseapp.com/__/auth/handler
The application and helper can use different domains. What matters is that the project's configuration, helper and Google callback agree.
A redirect can fail later than a popup
Check which sign-in method your application calls. Helpful Mods Foundation Kit uses signInWithPopup for its configured social providers. If Google opens and the popup reports an error, follow that error through the popup handler.
An app using signInWithRedirect has another interesting failure: the user completes Google sign-in, returns to the app, and appears signed out. Browser restrictions on third-party storage can interrupt the helper's return path. That can make the same deployment behave differently in Safari and another browser.
Firebase documents redirect setups for different hosting arrangements. Pick the option that matches yours. For its proxy option, /__/auth/ requests need to pass through transparently to the Firebase helper. A 302 sends the browser to the other domain again, which leaves the storage problem in place.
When Google has finished its part
If the browser has a Firebase user and the next API request fails, follow that request into the backend. Foundation checks the configured application origin and the verified identity. Compare APP_ORIGIN with the public URL and inspect the headers arriving through your proxy. Losing Authorization there can produce an API failure after a perfectly good Google sign-in. The Firebase API 401 guide works through that request in more detail.
Once the production sign-in works, open a protected screen and reload it. Then repeat it on the browser or phone that originally failed. The whole return to the application is the part you want working consistently.
Foundation Kit connects Firebase accounts with private and team workspaces, billing and support. Its deployment guide includes the domain and proxy settings alongside the source, so you can follow the request from the login button through to the application.