Firebase Authentication Authorized Domain Constraints Without Wildcards

A Firebase project using OAuth redirect or popup sign-in succeeds on localhost because Firebase implicitly authorizes localhost for development, but production origins must appear in the Authentication Authorized Domains list. The list does not support wildcard entries, so ephemeral preview URLs, regional subdomains, or multi-tenant hosts require explicit enumeration. Default Hosting domains are pre-authorized and custom Hosting domains are generally added automatically, yet origins outside Hosting such as Cloud Run or external load balancers require manual entry. Adding a domain applies project-wide across every app sharing the project.

Because custom auth domains require verified DNS records and SSL certificates, a team must decide whether to adopt a single verified custom auth domain to centralize redirects and reduce list churn, or to keep manually enumerating each production and preview domain and accept the operational overhead. An unverified or misconfigured auth domain can break redirects even when the origin domain is authorized.

1. Under what conditions does the operational cost of maintaining an enumerated Authorized Domains list exceed the DNS and certificate overhead of a single custom auth domain?
2. Do multi-tenant or ephemeral preview environments have a supported pattern that avoids wildcard entries without fully centralizing redirects?
3. How do the redirect_uri_mismatch and auth/unauthorized-domain failure modes differ when validating a new production origin?