Firebase authorized domains not working: domain is listed, sign-in still fails

1. Print what the browser is actually using

Paste this where you call getAuth() (Firebase JS SDK v9+ modular API), reload, and read the console:

import { getAuth } from "firebase/auth";

const auth = getAuth();
console.table({
  host: window.location.hostname,
  protocol: window.location.protocol,
  projectId: auth.app.options.projectId,
  authDomain: auth.app.options.authDomain,
  emulator: auth.emulatorConfig ? "yes" : "no",
});

auth.app.options holds the exact config passed to initializeApp(). Keep the output open; every check below compares against it.

2. Is it the same Firebase project?

Each project has its own list. If projectId above isn't the project you edited in the console, you added the host to the wrong list. This can happen when a deployed build reads a different set of environment variables than your local one.

Fix: add the host to the project in projectId, or point the build at the right config. If you use Firebase Hosting's reserved URLs, Firebase's FAQ suggests opening https://<authDomain>/__/firebase/init.json and checking that its projectId matches your firebaseConfig.

3. Is it the exact host?

The SDK compares each entry with window.location.hostname.

• www.example.com and example.com are different hosts. Listing www.example.com does not cover example.com, so add both if you serve both.
• Preview, staging and branch deploys each have their own host. See Firebase authorized domains: wildcards and subdomains.
• localhost and 127.0.0.1 are different entries; an IP address entry must match exactly. See auth/unauthorized-domain on localhost.
• If your app runs inside an iframe, such as an online builder's preview pane, the SDK checks the frame's own address, not the parent page's. Open the app in its own tab to see that host.

Fix: add the host exactly as hostname printed it.

4. Was the entry saved as a bare host?

Google's help page says an entry allows "any URL and port of that domain", so the list expects host names only. The SDK matches the entry against the bare host name, so an entry saved with a scheme, port or path (https://example.com, example.com:3000, example.com/app) never matches. This can happen when the list is written by the API or Terraform.

Fix: replace the entry with example.com. The list and its API are covered in Firebase authorized domains.

5. Is the page on http or https?

The SDK's domain check only matches pages served over http: or https: (or a chrome-extension: page). On anything else, such as a file opened from disk (file:), no entry can match, so you get auth/unauthorized-domain however complete the list is.

Fix: serve the page from a local dev server or your host.

6. Is the tab reusing an old result?

The SDK checks the list once per page load and keeps the result, including a failure, for that Auth instance. A tab that was open when you added the host keeps failing, and so can a dev server's hot reload that keeps the same page.

Fix: fully reload the page, or open a new tab. Google doesn't document a propagation delay for this list (as of Oct 2026); to confirm the change was saved, reload the console list or read it with the GET call in Firebase authorized domains.

7. Which page shows the error?

If the message is "This domain YOUR_REDIRECT_DOMAIN is not authorized to run this operation" and it appears on a different host from your app, Firebase's FAQ says "the hostname of the page where you saw this error is your current authDomain". It names two causes: the redirect domain isn't on the list, or the API key is invalid. If the domain is listed, go to checks 8 and 9. What authDomain does: Firebase authDomain explained.

8. Is the Browser API key intact?

Firebase's FAQ says the JS SDK uses your project's Browser key "to verify that a sign-in redirect URL is valid according to the list of authorized domains". Check it in Google Cloud console > APIs & Services > Credentials (as of Oct 2026):

1. Key deleted? In the Firebase console, open Project settings and click your web app under Your apps. Firebase creates a new key, named after the app's nickname instead of "Browser key". Update your config, and __/firebase/init.json if you self-host the sign-in helper, then redeploy.
2. API restrictions: Firebase's FAQ says the Firebase Authentication API must be in the key's list of allowed APIs. Firebase's API key page says a key missing a required API can produce API_KEY_SERVICE_BLOCKED or a 403 Forbidden error.
3. Self-hosted helper: the API key and projectId in your __/firebase/init.json must match your firebaseConfig.

9. Do website restrictions on the key include your site?

If you added Website restrictions (HTTP referrers) to the key, requests from a site that isn't on that list are rejected, even when the host is on Firebase's authorized domains list. The SDK turns the server's message into a code, so the error looks like auth/requests-from-referer-<origin>-are-blocked.

Fix: add every site that loads your Firebase config, and include your authDomain host too: Firebase's FAQ explains that the sign-in helper on that host obtains your API key along with the rest of your Firebase configuration, so its requests may be checked against the same restrictions. Google's pattern for a whole site is two entries:

example.com/*
*.example.com/*

Google's notes: a wildcard can replace a subdomain or path, but not sit in the middle (mysubdomain*.example.com is invalid); a restriction with a port matches only that port; and a restriction without a port matches any port. With gcloud, the referrers you pass replace the existing list:

gcloud services api-keys update KEY_ID \
  --allowed-referrers="example.com/*,*.example.com/*,your-project-id.firebaseapp.com/*"

Firebase advises testing key changes on a test key before changing a production key.

10. Is it a different setting with a similar name?

• Identity Platform: if you upgraded to Identity Platform, the console path is Identity Platform > Identity providers > Project settings > Add Domain. It's the same project-level list, so editing either console is enough. Tenants don't have separate lists.
• Email links and password resets: a continue URL on an unlisted host fails with auth/unauthorized-continue-uri ("The domain of the continue URL is not whitelisted"). The server reports it as UNAUTHORIZED_DOMAIN. Add the host of the url in your ActionCodeSettings.
• redirect_uri_mismatch: this comes from your OAuth client's redirect URIs, not from authorized domains. See Firebase Auth errors.
• Works against the emulator, fails live? The SDK skips this check entirely when it's connected to the Auth emulator (emulator: yes in step 1), so the emulator can't tell you whether the live list is right.

How to confirm it worked

1. Open the app on the failing host in a new tab.
2. Run the snippet from step 1 and check that host and projectId match the list you edited.
3. Start sign-in. If neither auth/unauthorized-domain nor a requests-from-referer error appears, the host and the key both accept it.