AWS ALB+Cognito+ECS Fargate OAuth2授权码模式登录401与重定向配置问题咨询

• OAuth2授权码模式完全可以通过ALB原生能力实现，不需要额外接入API Gateway
• ALB本身内置了与Cognito的OIDC集成能力，天生支持认证逻辑卸载，不需要在业务后端或额外中间层编写认证流程代码

你目前遇到的“认证后反复触发ALB认证流程、最终返回401”的问题，本质是Cognito应用客户端的回调URL配置不匹配：
ALB发起Cognito授权码流程时，会向Cognito传递固定格式的回调地址；只有该地址被纳入Cognito应用客户端的「允许回调URL」白名单，整个授权链路才能走通。如果白名单不匹配，Cognito会拒绝携带授权码重定向回ALB的环节，ALB无法完成“换授权码为Token、生成会话Cookie”的关键步骤，就会持续判定用户未认证，陷入认证循环，最终抛出401。

清理无效的错误回调配置 #

你当前在Cognito应用客户端中配置的以下3个地址都不适用ALB集成场景，全部移除即可：

• https://<app_client_address>.auth.<zone>.amazoncognito.com/idpresponse：这是前端应用直连Cognito登录场景的回调地址，ALB认证流程根本不会调用
• https://<app_client_address>.auth.<zone>.amazoncognito.com/ouath2/idpresponse：不仅属于上述无效场景，还存在拼写错误（ouath漏写字母t，正确拼写为oauth）
• https://<alb_address>.<zone>.elb.amazonaws.com/oauth2/idpresponse：这个路径本身是对的，但之前如果没被正确加入白名单，流程就会卡死

配置唯一必需的有效回调地址 #

在Cognito应用客户端的允许回调URL白名单中，添加ALB的内置固定回调路径即可：
https://<your_alb_full_dns>/oauth2/idpresponse

实操注意事项 #

• /oauth2/idpresponse是ALB的内置保留路径，整个换码、校验、生成会话Cookie的环节全由ALB自主处理，不会将该路径的请求转发到ECS后端，完全不需要你在后端新增任何对应接口
• 不需要将ECS业务路径、ALB根路径加入Cognito的允许回调列表，仅上述固定回调路径是流程必需的
• 配置ALB监听器的Cognito认证参数时，需确保授权端点、令牌端点、JWKS地址等OIDC配置与你所在区域的Cognito域名完全匹配，避免换Token环节校验失败
• 认证流程通过后，ALB会将合法用户的请求转发到关联的ECS目标组，后端服务可直接从ALB自动注入的请求头中获取用户身份信息，无需额外实现认证逻辑

完全匹配你期望的架构逻辑：

1. 未认证用户访问ALB上的受保护业务路径
2. ALB内置规则触发Cognito授权码流程，302重定向到Cognito登录页面
3. 用户在Cognito侧完成账号身份校验后，携带授权码重定向回ALB的/oauth2/idpresponse路径
4. ALB自动完成授权码换Token、身份校验、生成会话Cookie的全流程
5. ALB将合法请求转发到关联的ECS目标组，由后端微服务处理具体业务

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