Firebase JS 如何实现同一主域下所有子域的用户统一身份认证

原自定义实现方案的核心报错原因 #

• 凭据类型完全不匹配：signInWithCustomToken()接口要求的是Firebase服务端通过Admin SDK生成的专属自定义凭据，你从onAuthStateChanged回调里通过getIdTokenResult()拿到的是短期用户访问凭证（ID Token），直接传入必然触发auth/invalid-custom-token类报错。
• Cookie配置错误：跨域Cookie的匹配域配置为mycookiedomain，和实际业务域名myapp.com完全不匹配，浏览器会直接拦截该Cookie的下发，导致跨子域时根本读不到存储的token值。
• 持久化逻辑硬伤：即便修正了上述两个问题，直接存储ID Token的方案也存在本质缺陷——ID Token默认有效期仅1小时，没有配套的自动刷新机制，会频繁出现登录态莫名过期的问题。

官方原生零改造实现方案（推荐） #

同主域下的多子域登录态共享是Firebase Auth的原生支持能力，完全不需要自行实现Cookie存储、自定义token传递的复杂逻辑，只要修正基础配置即可实现状态自动同步：

• 配置所有子域到Firebase授权域列表：在Firebase控制台的Auth配置页，将app1.myapp.com、app2.myapp.com全部加入授权域白名单，避免SDK触发跨域拦截。
• 统一所有子域的初始化authDomain配置：每个子域初始化Firebase时，不要单独配置当前子域作为authDomain，必须统一填写根域myapp.com作为authDomain。这是SDK实现跨域存储互通的核心——SDK会基于统一的authDomain域名，将登录态持久化到根域下的共享存储中，所有匹配根域的子域都可以自动读取、识别登录状态。千万不要为每个子域单独配置自身域名作为authDomain，这种配置会让每个子域的SDK使用独立的存储上下文，完全无法实现状态互通。
• 显式配置持久化模式：初始化Auth实例时，指定持久化类型为browserLocalPersistence（长期登录）或browserSessionPersistence（会话级登录），确保SDK的存储作用域匹配统一的根域配置。
• 修正第三方登录回调配置：针对Facebook这类第三方跳转登录（signInWithRedirect），确保所有登录回调地址都指向统一配置的根域，避免跳转回来时的登录状态丢失。

跨子域模态登录的特殊场景修正 #

如果需要实现“在app2.myapp.com上弹出app1的统一登录模态框”这类跨子域交互，才需要使用自定义token方案，此时要按以下流程修正逻辑：

• 自定义token必须由服务端生成：绝对不要在前端拼接token，当用户在app1完成登录后，将用户UID传给自有后端，通过Firebase Admin SDK调用createCustomToken(uid)生成合法的自定义登录凭据，前端不直接接触ID Token的长期存储。
• 跨域传值采用安全通道：不要将自定义token存在裸Cookie中传递，而是通过iframe与宿主页面的postMessage通信机制传递值，通信时严格校验消息来源的origin，仅接受来自*.myapp.com域的消息，避免token被恶意窃取。
• 接收端初始化登录：app2的宿主页面拿到合法的自定义token后，再调用signInWithCustomToken()完成登录，SDK会自动将登录态写入统一的根域共享存储，实现两个子域的状态同步。
• 跨域Cookie配置修正：如果确实需要使用Cookie传递敏感值，必须将Cookie的匹配域设置为.myapp.com（前置的点代表所有子域均可访问），同时开启Secure、SameSite=Lax属性，避免被浏览器安全策略拦截。

常见报错排查清单 #

• 检查所有子域的Firebase初始化配置，确保authDomain统一为根域，没有各子域单独配置子域域名的情况。
• 检查Firebase授权域白名单，确认两个业务子域都被正确加入，没有遗漏。
• 确认传入signInWithCustomToken的凭据是后端Admin SDK生成的自定义token，不是前端获取的ID Token。
• 排查Cookie配置，确认作用域、安全属性符合浏览器跨域Cookie的要求。
• 检查第三方登录的回调配置，确保与Firebase授权域的配置完全匹配。

内容的提问来源于stack exchange，提问作者Kormi Web Solutions