单Firebase项目内多Firestore应用能否实现用户沙箱隔离？

单个Firebase项目确实仅包含一套全局的Authentication用户池，所有租户的用户会默认存储在这个共享池里；同时，V2的身份类Functions（如用户创建/删除触发器）是绑定到项目级Auth服务的，无法直接关联或限制到特定的Firestore数据库实例，你的这个判断没问题。

1. 利用Firebase Auth的多租户功能 #

Firebase Auth本身支持**多租户（Multi-Tenancy）**模式，你可以在单个Firebase项目内创建多个独立租户：

• 每个租户拥有完全隔离的用户池、身份验证配置（如登录方式、自定义声明）
• 结合V2 Functions的数据库指定能力，你可以为每个租户绑定对应的Firestore数据库实例，业务逻辑函数可以针对特定租户的数据库触发
• 在Firestore安全规则中，通过用户的租户ID（从Auth的租户上下文获取）限制用户仅能访问所属租户的数据库资源

这种方案既能实现用户体系和数据库的隔离，又不需要维护多个Firebase项目，管理成本相对较低。

2. 自定义租户标识+安全规则隔离 #

如果不想使用多租户功能，也可以在单个Auth池内给每个用户添加tenantId自定义声明：

• 用户登录时，通过Functions或客户端逻辑验证其所属租户，并将tenantId写入用户的自定义声明
• Firestore安全规则中检查用户的tenantId，确保只能访问对应租户的数据库实例
• V2业务Functions可以指定触发特定租户的数据库，实现逻辑隔离

这种方式是逻辑层面的隔离，用户数据还是在同一个Auth池里，但通过规则和声明实现了租户间的访问隔离，适合对隔离要求不是极高的场景。

3. 自定义身份验证层 #

完全脱离Firebase Auth，采用第三方身份服务（如自研认证系统、专业身份管理工具等）：

• 认证时返回包含租户ID的身份凭证
• 在Functions和Firestore安全规则中验证该凭证，并根据租户ID关联对应的数据库实例
• 这种方案灵活性最高，但需要额外维护身份服务的成本

如果你的业务要求完全物理隔离（比如合规要求、数据绝对隔离），那每个租户创建独立Firebase项目确实是最彻底的方案。这种方式下每个租户拥有独立的Auth、Firestore、Functions等所有资源，没有任何共享，但会带来更高的管理成本——你需要自动化创建项目、统一配置、监控等，可以通过Firebase管理API来批量操作。

内容的提问来源于stack exchange，提问作者Frédéric Camblor