采用外部身份认证的系统应当如何正确设计用户审计功能？

你当前的方案本身可正常运行，但确实存在厂商绑定、审计链路脆弱等潜在隐患，以下是更具扩展性的标准化设计方案：

现有方案的核心问题 #

• 厂商绑定风险：如果后续需要更换身份认证服务（比如迁移到Auth0、自研IAM体系），所有关联了Cognito用户ID的业务表、审计表都要做全量数据迁移，改造成本极高
• 性能与配额问题：Cognito侧存储的用户属性如果需要频繁查询，每次调用Cognito接口不仅增加接口耗时，还容易触发官方的调用频率阈值限制
• 审计数据失效风险：如果Cognito侧用户被硬删除，业务库中留存的Cognito用户ID会变成无意义的字符串，无法回溯用户的完整操作轨迹

推荐设计：本地用户主表 + 外部身份源映射层 #

核心逻辑是将业务关联的用户ID和外部身份源的用户ID完全解耦，分为两张表存储：

1. 本地用户主表 #

这张表的主键作为所有业务表、审计表的关联外键，完全和外部身份服务无关，示例表结构：

CREATE TABLE `users` (
  `id` bigint UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '本地全局唯一用户ID，全业务统一关联外键',
  `email` varchar(128) DEFAULT NULL COMMENT '用户邮箱，同步自身份源',
  `phone` varchar(32) DEFAULT NULL COMMENT '用户手机号，同步自身份源',
  `nickname` varchar(64) DEFAULT NULL COMMENT '用户昵称',
  `status` tinyint NOT NULL DEFAULT '1' COMMENT '用户状态：1正常、2禁用、3注销',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_email` (`email`),
  UNIQUE KEY `uk_phone` (`phone`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2. 外部身份源映射表 #

专门用来关联本地用户和各身份源返回的用户ID，天然支持多身份源绑定，示例表结构：

CREATE TABLE `user_identity_providers` (
  `id` bigint UNSIGNED NOT NULL AUTO_INCREMENT,
  `user_id` bigint UNSIGNED NOT NULL COMMENT '关联本地用户表的id',
  `provider` varchar(32) NOT NULL COMMENT '身份源标识：如aws_cognito、wechat、google',
  `provider_user_id` varchar(128) NOT NULL COMMENT '身份源返回的唯一用户ID，即你之前直接存储的Cognito用户ID',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_provider_user` (`provider`,`provider_user_id`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3. 配套业务逻辑调整 #

• 用户首次通过Cognito登录时，先查映射表是否存在对应provider_user_id的记录，不存在则先创建本地用户主表记录，再创建映射表关联关系
• 日常接口认证时，从Cognito Token中解析出provider_user_id，查询映射表拿到本地user_id，后续所有业务逻辑、审计日志都用这个本地user_id关联
• 定时/触发式同步Cognito侧的用户属性变更到本地用户主表，减少Cognito接口调用频率

方案优势 #

• 完全解耦业务和外部身份源，后续不管是更换身份源还是新增多身份源登录能力，都不需要修改任何业务表结构
• 即使用户在Cognito侧被删除，本地用户表和审计表的关联关系依然完整，不影响审计回溯
• 常用用户属性存储在本地，查询性能更高，也避免了Cognito接口调用限制的问题

补充说明：如果你的业务规模很小，后续也完全没有更换身份源的计划，直接存储Cognito用户ID也完全可行，上述优化方案更适合中大型业务或者对数据可控性要求高的场景。

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