未使用托管登录时AWS Cognito的HTTP Only Cookie配置疑问

针对你提出的三个疑问，直接给出明确的流程判断和技术细节：

问题1：客户端调用InitiateAuth后，Cognito重定向到Lambda生成Cookie？ #

这种方式不可行。Cognito的重定向逻辑仅适用于OAuth2授权码/隐式流的托管登录流程，而InitiateAuth属于自定义认证流（比如USER_PASSWORD_AUTH类型），其响应会直接返回给调用客户端，不会触发任何重定向动作。因此无法通过Cognito把令牌转发到Lambda再生成Cookie。

问题2：客户端把凭证发往Lambda，由Lambda调用Cognito拿令牌？ #

这是当前最适合你的可行方案，具体细节：

• 流程：客户端将用户名、密码发送到你集成了Lambda的API网关路由 → Lambda作为中间层，调用AWS SDK的InitiateAuth接口（和你之前客户端用的是同一个接口，认证类型选USER_PASSWORD_AUTH）向Cognito发起认证请求 → Lambda拿到Cognito返回的ID Token、Access Token、Refresh Token后，将这些令牌封装为HTTP Only、Secure、SameSite属性的Cookie返回给客户端。
• 无需走OAuth2授权码流：你不需要先获取授权码再调用/oauth2/token端点，因为InitiateAuth已经支持直接用用户名密码获取令牌，完全匹配你之前的技术栈。注意要给Lambda配置cognito-idp:InitiateAuth的IAM权限。

问题3：是否存在其他流程？ #

还有两种可选方案：

• 自定义认证触发器+会话管理：客户端依然调用InitiateAuth，但在Cognito用户池配置PostAuthentication触发器Lambda。当用户认证成功后，Cognito触发该Lambda，你可以在Lambda中生成自定义会话ID（比如存到DynamoDB，关联用户的Cognito令牌），然后通过客户端后续请求后端时返回的响应设置HTTP Only Cookie。这种方式需要你自行管理会话存储，Cognito不会直接传递令牌到触发器。
• OAuth2授权码流（无托管UI）：不使用托管登录UI，但手动实现授权码流逻辑：客户端构造请求跳转到Cognito的/oauth2/authorize端点获取授权码 → 客户端将授权码发送到Lambda → Lambda调用Cognito的/oauth2/token端点交换令牌 → Lambda设置HTTP Only Cookie。这种方式符合OAuth2最佳实践，但流程比InitiateAuth更复杂，需要处理授权码的获取和验证。

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