同一Firebase项目下多餐厅应用身份认证隔离问题求助

针对你遇到的Firebase Auth跨应用登录问题，以下是几种保留第三方登录能力且实现用户隔离的方案：

方案1：自定义声明（Custom Claims）+ 应用身份校验 #

这是最推荐的轻量方案，无需拆分项目：

• 当用户在某餐厅APP注册/登录（包括第三方登录）时，通过Firebase Admin SDK给该用户添加餐厅ID自定义声明，示例代码：

  // Admin SDK 设置自定义声明
  admin.auth().setCustomUserClaims(uid, { restaurantId: "restaurant_001" });
  

• 每个餐厅APP内置专属的restaurantId（可通过配置文件或后台接口获取），用户登录后，前端调用getIdTokenResult()获取自定义声明并校验：

  // 前端校验逻辑
  firebase.auth().currentUser.getIdTokenResult()
    .then((idTokenResult) => {
      const userRestaurantId = idTokenResult.claims.restaurantId;
      const appRestaurantId = "restaurant_001"; // 当前APP对应的餐厅ID
      if (userRestaurantId !== appRestaurantId) {
        firebase.auth().signOut();
        // 提示用户仅能在对应餐厅APP登录
      }
    });
  

• 所有后端业务接口（如菜单查询、预订提交）必须校验用户ID Token中的restaurantId，确保请求与用户所属餐厅一致，防止绕过前端校验的恶意操作。
• 优点：保留Firebase Auth全部功能（含第三方登录），项目管理成本低；缺点：需额外开发校验逻辑，依赖Admin SDK维护声明。

方案2：按餐厅拆分独立Firebase项目 #

若需要完全的数据隔离，可为每个餐厅创建独立Firebase项目：

• 每个餐厅APP对应单独的Firebase项目，Auth数据完全独立，用户账号自然无法跨应用登录。
• 可通过Firebase CLI或自动化工具（如Terraform）批量创建、管理项目，降低重复操作成本。
• 优点：彻底隔离，无额外校验逻辑；缺点：项目管理、计费、版本迭代的复杂度随餐厅数量增加而上升，适合餐厅规模较小的场景。

方案3：用户数据绑定餐厅ID，全链路校验 #

通过数据库关联用户与餐厅，实现登录后校验：

• 在Firebase Firestore/Realtime Database中为每个用户文档添加restaurantId字段，用户首次登录（含第三方登录）时完成绑定。
• 用户登录后，前端先查询数据库中该用户的restaurantId，与当前APP的餐厅ID对比，不匹配则强制登出。
• 后端所有业务接口必须先校验用户的restaurantId与请求目标餐厅ID一致，避免非法访问。
• 优点：实现灵活，可扩展用户与餐厅的其他关联逻辑；缺点：需维护额外的用户关联数据，校验逻辑相对繁琐。

不推荐方案 #

你提到的硬编码账号密码到数据库校验的方式，会完全丧失Firebase Auth的第三方登录、密码重置、安全风控等核心能力，且安全性极低，不建议采用。

内容的提问来源于stack exchange，提问作者Jorge Zapata