AWS Amplify JS 中 Cognito 令牌过期时的 GraphQL 授权问题解析

问题背景

在使用 AWS Amplify JS 开发 Angular 应用时，开发者遇到了一个棘手的授权问题：当 Cognito 的访问令牌(accessToken)恰好在其过期时刻被用于 GraphQL API 调用时，系统会抛出"Unauthorized"错误，而不是自动刷新令牌并重试请求。

问题现象

具体表现为：

1. 当 accessToken 过期时（通常在15-60分钟后，取决于配置）
2. 恰好在过期时刻发起 GraphQL API 请求
3. 系统抛出错误："Graphql Error running query [query]. Authmode Cognito. Error: Unauthorized"
4. 尽管存在有效的刷新令牌(refreshToken)，但系统未能自动刷新令牌

技术分析

令牌生命周期管理

AWS Cognito 使用三种主要令牌：

• ID 令牌：包含用户身份数据
• 访问令牌：用于授权 API 调用，有效期较短（通常15-60分钟）
• 刷新令牌：用于获取新的访问令牌，有效期较长（通常几天）

问题根源

问题的核心在于令牌刷新时存在竞态条件：

1. 当 accessToken 过期时，Amplify 客户端理论上应该自动使用 refreshToken 获取新令牌
2. 但在令牌恰好过期的瞬间发起请求时：
   • 客户端检测到令牌已过期
   • 但刷新机制未能及时完成
   • 导致 API 调用使用了已过期的令牌
   • 服务器返回 401 Unauthorized 错误

现有解决方案的局限性

开发者尝试了多种解决方案：

1. RxJS 重试机制：在错误时重试请求，但未能解决根本问题
2. 主动令牌刷新：在令牌即将过期前强制刷新，部分缓解了问题
3. 错误处理：捕获并忽略特定错误，但影响用户体验

深入技术细节

令牌刷新流程

标准的令牌刷新流程应该是：

1. 客户端检测到 accessToken 即将过期
2. 使用 refreshToken 向 Cognito 请求新的 accessToken
3. 更新本地存储的令牌
4. 使用新令牌继续 API 调用

竞态条件分析

问题出现在以下场景：

1. 令牌过期时间：T
2. API 调用时间：T ± ε（ε很小的时间窗口）
3. 在 T-ε 时，令牌仍被视为有效
4. 在 T+ε 时，服务器已认为令牌无效
5. 客户端尚未完成令牌刷新

解决方案探讨

临时解决方案

开发者提出的临时解决方案是在 GraphQL 请求头中添加令牌过期检查：

headers: async () => {
  try {
    let currentSession = await fetchAuthSession();
    const tokenExpiry = currentSession.tokens.accessToken.payload.exp * 1000;
    const HALF_MINUTE = 30000;
    const now = new Date().getTime() + HALF_MINUTE;
    if (tokenExpiry <= now) {
      currentSession = await fetchAuthSession({forceRefresh: true});
    }
    // 返回令牌...
  } catch (error) {
    // 错误处理
  }
}

理想解决方案

从架构角度看，理想的解决方案应包括：

1. 提前刷新机制：在令牌到期前一定时间（如5分钟）就开始刷新
2. 请求队列：在刷新期间暂停请求，刷新完成后继续
3. 错误恢复：对特定错误类型自动重试
4. 双令牌检查：同时验证 accessToken 和 refreshToken 状态

最佳实践建议

基于此问题的分析，建议开发者：

1. 实施主动刷新：在令牌到期前30秒-1分钟就开始刷新
2. 优化错误处理：区分临时性错误和永久性错误
3. 监控令牌生命周期：记录令牌签发和过期时间
4. 考虑服务端方案：对于关键业务，可考虑服务端令牌管理

总结

AWS Amplify JS 中的 Cognito 令牌管理在大多数情况下工作良好，但在令牌过期边界条件下存在竞态条件问题。开发者需要理解令牌生命周期，实施适当的预防措施，并建立健壮的错误处理机制，以确保应用在令牌轮换期间的无缝体验。

这个问题也提醒我们，在实现身份验证和授权流程时，边界条件的处理同样重要，需要与主流场景一样得到充分重视和测试。