Firebase Authentication Authorized Domain Constraints Without Wildcards

Direct answer

Firebase Authentication does not accept wildcard entries in Authorized Domains. Every browser origin that starts a sign-in flow must be listed. A custom auth domain is a different control: it stabilizes the redirect handler, but it does not automatically authorize arbitrary application origins.

Confirmed constraints

• Default Hosting domains are pre-authorized; custom Hosting domains are generally added automatically.
• Origins outside Hosting, such as Cloud Run or an external load balancer, must be added manually.
• Domain additions are project-wide across apps sharing the Firebase project.
• A custom auth domain still needs verified DNS and a trusted SSL certificate; a broken auth domain can fail redirects even when the app origin is authorized.

1. When does enumeration cost exceed one custom auth domain?

The documented behavior does not define a numeric break-even. The likely explanation is operational: enumerate while the number of distinct origins is small and stable. Move toward a single verified auth domain when preview deployments create frequent new origins, when multiple teams can forget an entry, or when a failed sign-in is more expensive than DNS/certificate upkeep. As a heuristic, more than roughly five to ten changing production/preview origins usually makes centralization worthwhile, but treat that as a planning threshold, not a Firebase limit.

2. Ephemeral or multi-tenant previews

There is no supported wildcard substitute. The practical pattern is to keep one stable sign-in origin or one stable auth domain and pass environment/tenant context through OAuth state or application routing. Per-PR subdomains under a parent you control still require enumeration unless the sign-in flow is redirected through a stable origin. For multi-tenant hosts, prefer a shared auth domain and tenant resolution by path/state over enumerating tenant hostnames.

3. Failure modes

auth/unauthorized-domain is Firebase-side: the current browser origin is not in Authentication > Authorized domains. redirect_uri_mismatch is provider-side: the redirect URI derived from your Firebase authDomain does not match an authorized redirect URI in the provider's OAuth client. Adding the origin fixes the first; correcting authDomain, DNS/SSL, or the provider redirect URI fixes the second.

Verification

firebase auth:domains:list
dig +short CNAME auth.example.com
openssl s_client -connect auth.example.com:443 -servername auth.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Assumption: current Firebase console/CLI behavior; confirm the exact domain maximum and automatic Hosting additions in your project because these can change. One diagnostic would change the recommendation: whether preview origins are subdomains of one parent you control or unrelated hosts.