基于AWS ALB/API Gateway的WebSocket认证方案疑问及优化咨询

初始评估的三种认证方案 #

• 方案1：部署在API Gateway之后
  AWS的WebSocket API Gateway仅支持HTTP服务器/Lambda作为后端，无法对接WebSocket服务器，此方案不可行。

• 方案2：部署在ALB之后（ALB+Cognito认证）
  ALB会检查请求中的AWSELBAuthSessionCookie，存在则转发请求，否则重定向到Cognito默认Hosted-UI（仅支持有限自定义）。我们已有自研自定义登录页，用AWS Amplify实现登录，但ALB集成Cognito要求客户端启用client-secret，而浏览器端Amplify无法使用带client-secret的Cognito客户端。
  我们尝试在API Gateway后搭建Lambda函数，接收前端哈希后的用户名密码，调用Cognito的InitiateAuth Python SDK完成认证获取access-token，但无法用该token生成AWSELBAuthSessionCookie，官方文档也未公开该Cookie的生成逻辑。最终结论：此方案仅能使用Cognito默认Hosted-UI，无法适配自定义登录页。

• 方案3：WebSocket服务器内完成认证
  浏览器与WebSocket服务器建立连接后发送JWT令牌，服务器校验令牌有效性，无效则终止连接，这属于基于票据的认证系统。

疑问解答 #

1. 基于票据的认证系统是否面临更高的DoS/DDoS攻击风险？ #

是的，相比在负载均衡层提前拦截未认证请求的方案，这种在服务器端做认证的模式确实会面临更高的DoS/DDoS风险：

• 恶意攻击者可以发起大量未携带有效JWT的WebSocket连接请求，服务器需要先建立连接、接收令牌、校验令牌，这个过程会消耗服务器的连接数、CPU和内存资源，直到校验失败才终止连接。
• 而如果在ALB这类负载均衡层提前拦截未认证请求，服务器不会收到这些无效请求，资源消耗会更低。

不过可以通过以下手段降低风险：

• 限制单IP的并发连接数，避免单个IP发起大量请求；
• 缩短WebSocket连接的超时时间，对未及时发送有效JWT的连接直接断开；
• 引入速率限制，对短时间内发起大量连接的IP进行临时封禁；
• 使用WAF过滤明显的恶意请求，比如携带异常请求头、不符合格式的JWT的请求。

2. 是否存在更优的WebSocket认证方案？ #

有几种更优的方案可以考虑：

• CloudFront + Lambda@Edge前置认证
  将CloudFront作为WebSocket请求的入口，在Viewer Request阶段用Lambda@Edge校验JWT令牌（可从请求头、Cookie或查询参数中获取）。如果令牌无效，直接返回403拒绝请求；如果有效，再将请求转发到EC2上的WebSocket服务器。这种方式能在边缘节点提前拦截无效请求，减轻EC2的压力，同时支持自定义登录页的认证流程。

• 双Cognito客户端+自定义Cookie认证
  创建两个Cognito客户端：一个不带client-secret的用于浏览器端Amplify登录，获取access-token和id-token；另一个带client-secret的用于后端服务，利用id-token在后端生成自定义认证Cookie，设置HttpOnly、Secure、SameSite等安全属性。WebSocket连接时携带该Cookie，服务器端校验Cookie有效性即可。此方案能适配自定义登录页，同时自己掌控Cookie的生命周期。

• 替换为AWS AppSync实时服务
  如果业务允许，直接使用AWS AppSync的实时WebSocket功能，它内置了与Cognito的集成，支持通过Amplify对接不带client-secret的Cognito客户端，适配自定义登录页，且AWS会负责底层的认证拦截和资源防护，无需自行维护EC2上的WebSocket服务器。

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