AWS Amplify 6 中获取 Refresh Token 的技术方案解析

背景介绍

在 AWS Amplify 身份验证模块的版本升级过程中，从 v4 升级到 v6 后，开发者发现 fetchAuthSession 方法不再返回 refresh token。这一变化给需要跨进程共享认证状态的场景带来了挑战，特别是在 Electron 应用架构中。

核心问题分析

在传统架构中，Electron 应用通常采用以下工作流程：

1. 用户在渲染进程（前端）完成身份验证
2. 将 refresh token 传递给主进程（后端）
3. 主进程使用 refresh token 维护会话状态并执行 API 调用

Amplify v6 出于安全考虑，刻意将 refresh token 设为内部使用，不通过公共 API 暴露。这种设计理念的变化需要开发者调整原有的实现方式。

解决方案详解

临时解决方案：直接读取存储

目前可以通过直接访问底层存储来获取 refresh token：

1. 首先读取 CognitoIdentityServiceProvider.{client_id}.LastAuthUser 获取用户名
2. 然后读取 CognitoIdentityServiceProvider.{client_id}.{username}.refreshToken
3. 最后解码获取的 refresh token

需要注意的是，这种方法不会自动通知后端进程用户重新认证的事件。

推荐架构方案

对于 Electron 应用，建议采用以下架构：

1. 前后端令牌同步：在渲染进程和主进程之间建立令牌同步机制
2. 自定义令牌提供者：在主进程配置自定义的 TokenProvider

import { Amplify } from 'aws-amplify';
import { TokenProvider, decodeJWT } from 'aws-amplify/auth';

const customTokenProvider: TokenProvider = {
  async getTokens() {
    // 从渲染进程获取最新的令牌
    const accessToken = '<从渲染进程获取的JWT>';
    const idToken = '<从渲染进程获取的JWT>';
    
    return {
      accessToken: decodeJWT(accessToken),
      idToken: decodeJWT(idToken),
    };
  },
};

Amplify.configure(config, {
  Auth: { tokenProvider: customTokenProvider }
});

令牌刷新机制

当使用 fetchAuthSession 时：

• 系统会自动检查令牌有效期
• 过期时会自动触发刷新流程
• 无需手动处理 forceRefresh 参数（除非有特殊需求）

安全注意事项

1. 最小权限原则：只传递必要的访问令牌(access token)而非刷新令牌
2. 令牌生命周期管理：确保前后端令牌状态同步
3. 存储安全：妥善保护本地存储中的敏感信息

未来演进方向

虽然当前需要通过变通方案实现功能，但 Amplify 团队正在收集类似场景的需求。开发者可以关注官方更新，未来版本可能会提供更优雅的跨进程认证方案。

对于必须使用 refresh token 的场景，建议评估是否真的需要直接操作 refresh token，很多情况下使用 access token 配合自动刷新机制是更安全的做法。