How to Use Firebase Auth Across Multiple Domains Without Whitelisting Every Domain

1.Why This Happens

If you have ever tried to build something embeddable, you have probably hit this wall.

Everything works fine on your own website. Then you give your customers a simple script to embed, and suddenly Google login breaks with an error like:

At first it feels like a configuration issue. Maybe you forgot to add a domain. Maybe Firebase is acting up.

But the truth is simpler and more frustrating.

So if your widget is embedded on a client website, Firebase sees that domain and asks - is this domain allowed? If the answer is no, it blocks the login.

There is no wildcard support. You cannot say allow all domains. That is the core limitation.

2.The Wrong Way to Solve It

A lot of people try this first - add every client domain to Firebase and keep updating the list as new customers come in.

This works for a few users. Then it becomes a mess.

• You forget to add a domain
• Customers complain login is broken
• Preview URLs and staging sites fail
• You spend time fixing config instead of building product

3.The Simple Shift That Fixes Everything

The solution is not to fight Firebase.

The solution is to change where authentication happens.

Instead of running Firebase Auth inside the widget, you move it to a domain you control. Think of it as adding a small layer in between.

4.Step 1 - Use Your Own Domain for Authentication

Set up a dedicated auth page on your domain.

This is the only place where Firebase runs. In Firebase settings, you only authorize:

• yourproduct.com
• auth.yourproduct.com

5.Step 2 - Trigger Login From the Widget

Now your widget becomes simple. When a user clicks Login with Google, instead of calling Firebase directly, it opens your auth page:

This can be a popup or a redirect. At this point, the user is no longer on the client's website.

They are on your domain. Firebase is happy.

6.Step 3 - Authenticate and Generate a Token

Once the user logs in:

• Firebase verifies the user
• Your backend creates a session or JWT token
• This token represents the logged-in user

7.Step 4 - Send the Token Back to the Widget

Now you pass that token back to the widget using a browser feature called postMessage.

The widget receives the token and stores it. From this point on:

• The widget does not need Firebase
• It just sends API requests with the token
• Simple and clean

8.Why This Works

Because Firebase only ever sees your domain.

It never sees client websites. It never blocks anything. You have created a safe authentication layer that sits between Firebase and the outside world.

• clientwebsite.com - Firebase never sees it
• anotherclient.com - Firebase never sees it
• randomblog.net - Firebase never sees it

If authentication depends on customer domains, your product becomes fragile. If authentication depends on your domain, your product becomes stable.