如何修复Amazon Cognito Cookie大小超4K引发的Nginx 400错误？

以下是几个不破坏登录功能的实用调整方案，按实现复杂度和见效速度排序：

1. 临时缓解：调整Nginx的请求头缓冲区配置 #

这是最快见效的方案，无需修改应用代码，直接调整Nginx参数容纳现有Cookie大小：

• 在Nginx的http、server或目标location块中添加/修改以下配置：

  # 增大客户端请求头缓冲区，默认是4个4k缓冲区，改成4个8k
  large_client_header_buffers 4 8k;
  # 调整单个请求头的缓冲区大小，默认1k，改成2k
  client_header_buffer_size 2k;
  

  重启Nginx后即可解决400错误，适合作为临时修复或配合其他长期方案使用。

2. 源头缩减：精简Cognito令牌的声明内容 #

Cognito的idToken和accessToken大小主要由其中包含的用户声明（Claims）决定，通过精简这些内容可以从根本上减小Cookie体积：

• 限制OAuth请求范围：在Cognito用户池的应用客户端设置中，只勾选业务必需的OAuth范围，比如仅保留openid、email（如果需要用户邮箱），去掉默认的profile（包含昵称、头像等非必要字段）。
• 过滤不必要的用户属性映射：在Cognito用户池的“属性映射”页面，仅将业务必需的用户属性（如用户ID、邮箱）映射到令牌中，移除所有非必要属性的映射。
• 使用Lambda触发器修剪令牌：创建Cognito的Pre Token Generation Lambda触发器，在令牌生成前过滤掉冗余声明。示例代码（Node.js）：

  exports.handler = async (event) => {
    // 保留必要的claims，比如sub、email、iss等
    const allowedClaims = ['sub', 'email', 'iss', 'exp', 'iat'];
    event.response.claimsOverrideDetails = {
      claimsToSuppress: Object.keys(event.request.userAttributes).filter(claim => !allowedClaims.includes(claim))
    };
    return event;
  };
  

3. 存储优化：调整令牌的客户端存储方式 #

针对Next.js应用，可以通过修改令牌存储逻辑，减少Cookie中的大体积内容：

• 将Refresh Token移至服务器端存储：登录成功后，将Cognito的refreshToken存入Redis等服务器端会话存储，客户端仅存储一个短会话ID（HttpOnly Cookie）。后续令牌刷新通过Next.js API路由完成，API路由根据会话ID从Redis获取refreshToken调用Cognito接口。这种方式可以直接移除体积最大的CognitoIdentityServiceProvider.refresh Cookie。
• 前端令牌存储优化：如果业务允许，将idToken和accessToken存在内存或localStorage（注意防范XSS风险），仅用Cookie存储必要的会话标识。但此方案需要确保令牌刷新逻辑在前端或API路由中正确处理，避免登录状态丢失。

4. 次要优化：压缩JWT令牌（可选） #

Cognito令牌是Base64编码的JWT，虽然压缩空间有限，但可以尝试对令牌进行gzip压缩后再存入Cookie，前端和后端需要分别处理压缩和解压缩逻辑。不过此方案实现复杂度较高，仅在前面的方案无法满足需求时考虑。

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