使用C#后端修改Firebase Token中的“sub”声明

核心前提 #

仅在用户合并、系统迁移等必须统一用户标识的合规场景下操作，所有修改需满足数据隐私法规要求，并已完成安全风险评估。

1. 官方合规途径：使用Firebase Admin SDK生成自定义Token #

直接修改已签发的Firebase ID Token会导致签名失效，无法通过官方验证。唯一合规方式是通过Admin SDK生成自定义Token，指定自定义UID作为sub声明：

步骤1：初始化Firebase Admin SDK（C#）

var app = FirebaseApp.Create(new AppOptions()
{
    Credential = GoogleCredential.FromFile("path/to/your-service-account.json"),
});

步骤2：生成带自定义UID的Token

var auth = FirebaseAuth.DefaultInstance;
// 替换为你的自定义唯一用户标识（需保证全局唯一）
string customUid = "legacy-system-user-12345";
var customToken = await auth.CreateCustomTokenAsync(customUid);

客户端需调用Firebase Auth的signInWithCustomToken方法登录，后续获取的ID Token中sub即为指定的customUid。

2. 建立用户标识映射关系 #

若涉及用户数据迁移，需在Firebase数据库（Firestore/Realtime Database）中存储自定义UID与原Firebase用户UID的映射，确保数据关联：

FirebaseFirestore db = FirebaseFirestore.DefaultInstance;
await db.Collection("user_uid_mappings").Document(customUid).SetAsync(new
{
    original_firebase_uid = "firebase-default-uid-67890",
    created_at = Timestamp.FromDateTime(DateTime.UtcNow),
    migration_reason = "Legacy system user migration"
});

3. 严格管控自定义UID规则 #

• 保证UID全局唯一性：优先使用UUID、旧系统唯一用户ID等无冲突标识
• 禁止使用敏感数据：避免将邮箱、手机号、身份证号等作为UID
• 生成审计日志：记录每个自定义UID的生成时间、操作者、关联原用户信息，满足合规审计要求

4. 适配后端验证流程 #

后端接收ID Token时，除常规验证外，需额外校验sub的合法性：

// 验证ID Token有效性
var decodedToken = await auth.VerifyIdTokenAsync(clientIdToken);
string requestSub = decodedToken.Claims["sub"].ToString();

// 检查映射表中是否存在该自定义UID
var mappingSnapshot = await db.Collection("user_uid_mappings").Document(requestSub).GetSnapshotAsync();
if (!mappingSnapshot.Exists)
{
    throw new UnauthorizedAccessException("Invalid custom user identifier");
}

5. 合规与审计要求 #

• 保留用户同意记录：若涉及用户数据迁移，需留存用户同意将原标识替换为自定义UID的书面/电子记录
• 日志留存：所有自定义Token生成、UID映射操作的日志需至少留存6个月，以备合规检查

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