Firestore多项目多认证场景下，规则中识别用户来源并管控权限问询

我刚好处理过类似的跨项目Firestore权限配置需求，核心思路是从用户的认证令牌中提取来源项目的标识，然后在项目C的Firestore规则中基于这个标识做权限判断。下面分两种可靠的方案来实现：

方案一：利用自定义声明（Custom Claims）标记用户来源 #

这种方式灵活性更高，适合后续可能新增更多项目的场景。

步骤1：给项目A/B的用户添加自定义声明 #

通过Firebase Admin SDK，给项目A的授权用户统一添加project: "A"的自定义声明，项目B的用户添加project: "B"。示例代码（Node.js）：

// 项目A的Admin SDK代码
const admin = require('firebase-admin');
admin.initializeApp();

// 给指定用户添加项目标识声明
admin.auth().setCustomUserClaims('用户UID', { project: "A" })
  .then(() => {
    console.log('自定义声明已设置');
  })
  .catch(err => {
    console.error('设置声明失败:', err);
  });

// 项目B同理，将"A"替换为"B"即可

自定义声明会被嵌入到用户的ID Token中，且无法被客户端篡改（由Firebase签名保证）。

步骤2：在项目C的Firestore规则中判断并配置权限 #

编写规则时，先提取用户的自定义声明，再根据来源项目分配权限：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 辅助函数：获取用户的来源项目标识
    function getUserSource() {
      return request.auth.token.project;
    }

    // 所有文档的通用权限规则
    match /{document=**} {
      // A/B的授权用户都能读取文档
      allow read: if getUserSource() in ["A", "B"];
      // A/B的用户都能创建、更新文档
      allow create, update: if getUserSource() in ["A", "B"];
      // 仅项目B的用户能删除文档
      allow delete: if getUserSource() == "B";
    }
  }
}

方案二：利用ID Token的Issuer字段识别项目来源 #

每个Firebase项目的Auth服务都有唯一的Issuer（iss）字段，格式为https://securetoken.google.com/[项目ID]。这种方式无需额外设置自定义声明，适合固定的少数项目场景。

直接在项目C的Firestore规则中判断Issuer #

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 辅助函数：判断是否来自项目A
    function isFromProjectA() {
      return request.auth.token.iss == "https://securetoken.google.com/你的项目AID";
    }

    // 辅助函数：判断是否来自项目B
    function isFromProjectB() {
      return request.auth.token.iss == "https://securetoken.google.com/你的项目BID";
    }

    match /{document=**} {
      allow read: if isFromProjectA() || isFromProjectB();
      allow create, update: if isFromProjectA() || isFromProjectB();
      allow delete: if isFromProjectB();
    }
  }
}

关键注意事项 #

• 确保项目A/B的用户登录后，能获取到有效的ID Token，并用这个Token请求项目C的Firestore资源。
• 两种方案的权限判断都是基于Firebase签名的ID Token，安全性有保障，无需担心用户篡改标识。
• 如果你的项目涉及更复杂的权限逻辑（比如不同集合的差异化权限），可以在规则中针对特定集合单独编写判断逻辑。

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