使用Cognito ID作为Django用户模型主键的利弊及风险分析

方案1：独立UUID主键 + 单独cognito_id字段 #

对应的模型代码：

class User(AbstractUser):
    user_id = models.UUIDField(primary_key=True, default=uuid4) 
    cognito_id = models.UUIDField(default=uuid.uuid4, editable=False)

优点 #

• 解耦外部依赖：数据库主键完全由自身控制，和Cognito服务彻底分离。就算Cognito故障、账号被删除或ID规则变更，数据库内的用户数据关联逻辑不会直接崩溃。
• 主键稳定性高：UUID主键生成后不会变动，不会因外部服务操作（比如Cognito账号重置、ID更新）影响订单、用户资料等关联表的外键关系。
• 迁移灵活：后续替换Cognito为其他认证服务时，仅需修改cognito_id字段逻辑，无需改动主键和所有关联表，迁移成本极低。

缺点 #

• 字段冗余：多维护一个主键字段，增加少量存储开销（UUID占用空间不大，但属于额外字段）。
• 需手动维护唯一性：要给cognito_id加unique=True约束，否则可能出现同一Cognito ID对应多个用户的情况。
• 查询多一步匹配：通过Cognito ID查用户时需先匹配cognito_id字段，但PostgreSQL对UUID字段的索引优化成熟，性能影响可以忽略。

方案2：直接用Cognito ID作为主键 #

对应的模型代码：

class User(AbstractUser):
    cognito_id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)

优点 #

• 字段精简：少一个主键字段，数据结构更简洁，无需维护额外UUID主键。
• 查询直接高效：通过Cognito ID查用户时直接用主键检索，不需要额外字段匹配（实际场景中性能差异极小）。
• 天然一致性：主键即Cognito ID，从根源避免同一Cognito ID对应多个用户的问题，无需额外加唯一约束。

缺点 #

• 强绑定Cognito：数据库主键完全依赖Cognito服务，一旦Cognito不可用，所有依赖用户主键的操作（如查询订单、修改资料）都会受影响。
• ID变更风险：虽然Cognito ID一般不会变动，但特殊场景下（如AWS内部调整、账号合并迁移）若ID变更，需修改数据库主键及所有关联表的外键，操作风险极大。
• 迁移成本极高：后续替换认证服务时，必须修改所有关联表的外键字段，还要批量更新用户主键，数据量大时几乎不可控。

方案2的潜在问题 #

除上述缺点外，直接用Cognito ID当主键还有几个易忽略的风险：

• 残留数据冲突：Cognito账号删除后，数据库内用户主键仍存在，若新用户的Cognito ID与残留主键重复（UUID4重复概率极低但理论存在），会引发数据冲突。
• 权限隐患：若Cognito ID泄露，攻击者可直接通过主键访问用户关联数据，相比独立主键，攻击路径更直接（虽Django权限系统会做控制，但主键暴露增加风险）。
• 测试不便：本地或自动化测试时，需模拟Cognito的ID生成逻辑，或使用固定ID，不如独立UUID主键灵活，测试成本更高。

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