Cognito访客绑定用户池身份咨询：访客转注册用户流程设计

你的场景可以结合Cognito的现有能力+少量自定义逻辑实现，不需要完全自行管理访客，具体拆解如下：

核心能力复用 #

1. 访客临时访问的权限控制 #

Cognito本身支持未认证身份（Unauthenticated Identities），但直接用是全局匿名权限，不符合你「仅访问指定数据」的需求。可以这么落地：

• 已登录用户创建数据库条目后，后端生成关联该条目的临时令牌（包含条目ID、过期时间等信息），通过邮件发送给访客。
• 访客点击链接时，后端先验证令牌有效性，再调用Cognito API为该访客生成临时未认证身份，同时绑定自定义IAM策略——这个策略仅允许访问对应的数据库条目（比如通过DynamDB细粒度权限、API Gateway资源级授权实现）。
• 用这个临时身份的凭证（ID Token/Access Token）让访客访问数据，确保只能查看分配的内容。

2. 访客转注册后的权限升级 #

当访客选择注册时，直接复用Cognito用户池的注册流程：

• 注册完成后，触发Cognito的Post Confirmation Lambda触发器，在触发器里把新注册用户和之前临时令牌对应的条目关联（比如把用户ID写入数据库的条目权限表）。
• 同时更新该用户的Cognito自定义属性或用户组，赋予编辑对应资源的权限（比如加入「条目编辑者」用户组，绑定对应的IAM编辑策略）。

需要自行实现的部分 #

• 临时邀请令牌的生命周期管理：自己生成、存储（比如存数据库）、验证令牌的有效性和过期时间，避免无效链接访问。
• 资源与用户的关联逻辑：数据库里需要维护「条目-用户」的权限映射，确保注册后的用户能精准关联到自己被邀请的条目。
• 细粒度权限绑定：需要把Cognito身份（无论未认证还是已认证）和具体数据库条目权限绑定，这部分可能需要结合IAM资源级策略或后端权限校验逻辑。

替代简化方案 #

如果不想用未认证身份，也可以直接生成短期Cognito Access Token：

• 已登录用户创建条目后，后端通过Lambda调用Cognito的AdminCreateUser生成临时用户（设置临时密码，标记为未激活），再生成带该用户ID和条目ID的临时链接。
• 访客访问时，后端用这个临时用户身份生成短期Access Token，仅赋予查看权限。
• 访客注册时，直接激活该临时用户（或让用户关联自己的邮箱/手机号完成注册），然后升级权限为编辑。

这种方式不需要处理未认证身份，但需要管理临时用户的生命周期（过期后自动删除）。

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