API Gateway V2结合AWS Authorizer设置HTTP Only Cookie实现鉴权

• 原生Cognito Authorizer完全不支持你描述的自动处理逻辑，没有任何配置项可以开启相关能力。
• 你的需求完全可以实现，不需要在每个业务Lambda里写重复代码，核心方案是自定义REQUEST类型Lambda授权器 + API Gateway全局响应映射，整套逻辑对现有业务Lambda透明。
• 你提到的「授权器无法直接设置响应头」是对的，但这个限制可以通过API Gateway层的通用配置绕开，不需要侵入业务代码。

原生托管的Cognito授权器是固定逻辑的托管组件，自定义空间为0，和你的需求存在明确冲突：

• 仅支持从请求的Authorization请求头提取Bearer <token>格式的凭证做校验，不会主动读取Cookie中的内容
• 没有token过期自动刷新的执行逻辑，校验失败直接返回401响应，不会主动调用Cognito令牌端点换发新token
• 没有修改响应头的能力，无法主动写入Set-Cookie头操作Cookie
• 无法插入自定义校验逻辑，比如跨站请求伪造校验、用户状态二次校验等

整套逻辑所有公共能力全部下沉到网关层和独立公共Lambda，业务Lambda不需要写任何鉴权、Cookie处理、token刷新相关代码。

1. 登录回调环节的HttpOnly Cookie写入 #

不要把Cognito的回调地址指向React前端，直接指向一个独立的、非业务的回调处理Lambda：

• 该Lambda接收Cognito重定向带回的code参数，在服务端调用Cognito令牌端点，用授权码兑换access_token、id_token、refresh_token
• 兑换成功后构造302重定向响应，通过Set-Cookie头把三个令牌写入HttpOnly Cookie：
  • access_token、id_token设置Max-Age=3600，和令牌本身有效期对齐
  • refresh_token设置Max-Age和你在Cognito用户池配置的刷新令牌有效期一致（通常为30天）
  • 所有Cookie必须配置Secure（生产环境强制HTTPS传输）、HttpOnly（禁止JS读取）、Path=/，同域部署时SameSite=Strict，跨域部署时SameSite=None
• 重定向目标指向React前端的登录成功页即可，前端全程无法读取任何令牌内容，从根源避免XSS导致的令牌泄露。

2. 自定义授权器的校验与刷新逻辑 #

给API Gateway所有需要鉴权的路由绑定REQUEST类型的自定义Lambda授权器，该授权器作为公共组件统一处理所有鉴权逻辑：

• 授权器触发后，直接从请求头的Cookie字段中解析出存储的access_token和refresh_token
• 优先校验access_token的签名、过期时间、权限范围、用户状态：
  • 校验通过：生成允许访问的IAM策略，把用户ID、用户组、自定义属性等信息放到授权器返回的context字段中，透传给后端业务Lambda，业务Lambda直接从事件对象里读取用户信息即可
  • access_token校验失败（过期/签名非法）但refresh_token有效：直接在授权器内调用Cognito的刷新令牌接口，用refresh_token兑换新的access_token和id_token，把新令牌字符串放到返回的context的自定义字段（比如new_auth_cookie）中，同时生成允许访问的策略
  • 两个令牌都失效：生成拒绝访问的策略，同时在context中带上清除Cookie的指令
• 给授权器开启缓存，缓存键取Cookie中的access_token值，缓存TTL设为3600秒（和access_token有效期对齐），缓存命中时不会重复执行校验逻辑，性能和原生Cognito授权器基本一致，同时能降低Lambda调用成本。

3. API Gateway全局配置实现Cookie自动写入 #

针对授权器无法直接设置响应头的问题，通过API Gateway的全局集成响应/网关响应模板配置解决，不需要修改任何业务Lambda：

• 在API Gateway配置通用响应映射模板，判断授权器透传的context中是否存在new_auth_cookie字段：如果存在，自动在响应头中添加Set-Cookie字段，值为新的令牌Cookie字符串，实现新令牌自动写入
• 如果context中存在清除Cookie的指令，自动在响应头中添加过期时间为0的Set-Cookie字段，清空失效令牌，同时返回401状态码引导前端跳转登录页
• 该配置是API Gateway层全局生效的，所有绑定了该自定义授权器的路由都会自动执行该逻辑，不需要给每个接口单独配置。

• CSRF防护：在登录回调写入Cookie时，额外生成一个随机CSRF令牌，存为非HttpOnly的Cookie，前端读取该令牌放到每次请求的自定义请求头中；授权器校验时对比Cookie中的CSRF值和请求头中的CSRF值，不一致直接拒绝访问
• 接口权限控制：在授权器中维护路由-用户组的映射表，校验access_token中的用户组是否有当前请求路由的访问权限，无权限直接返回403，不需要在每个业务Lambda里做权限判断

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