Firebase Admin SDK同Gmail账号多应用自定义声明是否覆盖

你担心的覆盖问题确实会发生。admin.auth().setCustomUserClaims(uid, claims) 接口的行为是全量替换用户账号下存储的整个自定义声明对象，不会做增量字段合并。
按照你给出的代码逻辑：

1. 用户先使用客户端应用，Cloud Function写入仅包含clientFeatureA、clientFeatureB的声明对象，此时用户的自定义声明只有这两个客户端相关字段
2. 用户再使用服务端应用，Cloud Function直接传入仅包含serverFeatureA、serverFeatureB的声明对象调用接口，会直接把之前存储的客户端字段全部抹除，最终用户的自定义声明只剩服务端相关的两个字段；反过来如果先调用服务端再调用客户端，服务端的字段也会被客户端覆盖。

不管是服务端还是客户端的Cloud Function，在更新自定义声明前，必须先拉取用户当前已有的声明，在已有声明基础上合并当前端需要新增/修改的字段，再传入更新接口，示例代码如下：

// 服务端更新声明的正确写法
// 1. 先查询目标用户的现有信息
const userRecord = await admin.auth().getUser(uid);
// 2. 读取已存在的自定义声明，新用户没有声明时默认取空对象
const existingClaims = userRecord.customClaims || {};
// 3. 合并当前端需要设置的字段，注意不同业务端的声明字段不要重名避免冲突
const mergedClaims = {
  ...existingClaims,
  serverFeatureA: true,
  serverFeatureB: false
};
// 4. 传入合并后的完整声明对象执行更新
await admin.auth().setCustomUserClaims(uid, mergedClaims);

客户端应用的Cloud Function更新逻辑和上面完全一致，只需要把合并的字段换成clientFeatureA、clientFeatureB即可。

• 自定义声明的总 payload 大小不能超过1000字节，只适合存储权限校验必需的轻量字段（比如功能开关、角色标识），不要把业务数据、用户资料类的内容塞到声明里
• 声明更新后不会立即在用户端生效，需要等用户的ID Token自动刷新，或者客户端主动调用getIdToken(true)强制刷新本地缓存的token，才能拿到最新的声明值做权限判断

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