如何在Cognito中实现访客用户访问权限

核心结论 #

Identity Pool 不是实现访客访问的唯一方案，针对你仅需访问API Gateway、且API同时面向已认证用户开放的场景，优先推荐和现有认证流程兼容性更高的替代方案。

可行方案对比 #

方案1：Cognito 用户池虚拟访客方案（最适配你的场景） #

• 实现逻辑：和你原有自有系统的访客逻辑完全对齐，在Cognito用户池中按需创建专属的访客用户，为用户添加custom:user_type = guest的自定义属性标记访客身份，后端封装专用的访客获取令牌接口：匿名用户请求访客权限时，后端直接调用Cognito的AdminInitiateAuth接口完成后台登录，返回和普通已认证用户格式完全一致的ID Token/Access Token给前端
• 优势：
  • 完全复用现有API Gateway的Cognito授权器配置，无需修改授权逻辑
  • 访客自定义属性会自动编码到JWT令牌中，API Gateway可直接解码透传给后端服务，无需额外开发
  • 已认证用户和访客用户的调用流程完全统一，前端适配成本极低
• 注意点：可将访客用户的令牌有效期设置为更短的时长，同时定期清理过期的访客用户，避免用户池产生无效账号堆积

方案2：API Gateway双授权器方案 #

• 实现逻辑：同一组API同时配置两个授权器：原有Cognito用户池授权器面向已认证用户，新增自定义Lambda授权器面向访客用户，访客令牌可由你的业务后端自行生成，Lambda授权器完成访客令牌校验后返回自定义上下文信息给后端
• 优势：无需在Cognito用户池中创建额外的访客账号，适合访客量级极大、不想占用用户池账号额度的场景

方案3：Identity Pool未认证身份方案（不推荐你的场景使用） #

• 实现逻辑：开启Identity Pool的未认证身份支持，为未认证身份分配专属IAM角色，API Gateway修改为IAM授权方式，访客和已认证用户都通过Identity Pool换取的IAM签名凭证调用接口
• 劣势：
  • 需要同时修改已认证用户的调用流程，改造成本最高
  • 若要附加访客自定义信息，需要额外配置Identity Pool的Principal标签或者新增Lambda授权器解析身份上下文，额外开发量大
  • 仅适合访客需要访问除API Gateway外其他AWS资源的场景

选型建议 #

你的场景优先选择方案1，改造成本最低，完全匹配现有技术栈的使用习惯，不需要调整已有的API授权和后端鉴权逻辑。

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