React Native持久化登录认证流程优化咨询

核心思路落地 #

针对你提出的「同一设备极少重新登录」+「Refresh Token一次性轮换」需求，结合设备绑定+非对称签名的思路，以下是可落地的技术方案：

1. 设备唯一标识与密钥对生成 #

• 设备标识获取：使用expo-device的Device.deviceId作为设备唯一标识，注意：iOS端卸载重装应用后该ID会变更，Android端部分厂商设备可能因系统限制有变动，但足以作为设备绑定的依据。
• 非对称密钥生成：在用户首次登录时，客户端通过expo-crypto生成RSA密钥对，将公钥与设备ID一起传给服务端，服务端关联用户ID存储这两个信息；私钥则存储在expo-secure-store或react-native-keychain中，绝对不能存在明文存储的AsyncStorage。

2. Refresh Token轮换与过期兜底 #

• 正常刷新流程：
  1. 每次发起API请求前，解析AccessToken的exp字段判断是否即将过期（比如提前300秒）。
  2. 若过期，用当前Refresh Token调用服务端刷新接口，获取新的AccessToken和一次性使用的Refresh Token。
  3. 客户端立即用新令牌替换旧令牌，存入安全存储。
• Refresh Token过期后的兜底：
  当Refresh Token过期时，不直接引导登录，而是发起「设备验证刷新请求」：
  1. 客户端用私钥对用户ID+设备ID+当前时间戳进行签名。
  2. 将签名、用户ID、设备ID传给服务端。
  3. 服务端验证签名（用绑定的公钥）、时间戳（防止重放攻击）、设备绑定关系，验证通过则发放新的AccessToken和Refresh Token。

3. 安全存储与并发控制 #

• 敏感数据存储：所有令牌（AccessToken、Refresh Token）、私钥必须存入expo-secure-store，示例代码：

  import * as SecureStore from 'expo-secure-store';
  
  // 存储令牌
  await SecureStore.setItemAsync('refreshToken', newRefreshToken);
  // 获取令牌
  const refreshToken = await SecureStore.getItemAsync('refreshToken');
  

• 并发请求防重复刷新：避免多个请求同时触发刷新操作，用全局Promise锁控制：

  let refreshInProgress = null;
  
  async function getValidAccessToken() {
    const accessToken = await SecureStore.getItemAsync('accessToken');
    if (isTokenExpired(accessToken)) {
      if (!refreshInProgress) {
        refreshInProgress = performTokenRefresh();
      }
      await refreshInProgress;
      refreshInProgress = null;
      return SecureStore.getItemAsync('accessToken');
    }
    return accessToken;
  }
  
  // 辅助函数：判断令牌是否过期
  function isTokenExpired(token) {
    if (!token) return true;
    const payload = JSON.parse(atob(token.split('.')[1]));
    const now = Date.now() / 1000;
    return payload.exp < now - 300; // 提前5分钟判定过期
  }
  

4. 服务端配合要点 #

• 绑定关系存储：维护一张用户设备绑定表，字段包括user_id、device_id、public_key、last_refresh_time。
• 双模式刷新接口：
  • 正常刷新接口：接收Refresh Token，验证有效性后返回新令牌，同时更新绑定表中的当前Refresh Token。
  • 设备验证刷新接口：接收用户ID、设备ID、签名、时间戳，验证签名合法性、设备绑定关系、时间戳有效期（比如5分钟内），验证通过则发放新令牌。
• 安全限制：
  • 限制每个用户绑定的设备数量（比如最多5台），超过则需用户手动移除旧设备。
  • 对设备验证请求增加频率限制，防止暴力攻击。

5. 风险权衡与补充措施 #

• 设备变更处理：iOS卸载重装或Android设备ID变更时，设备绑定关系失效，此时需引导用户重新登录，这是合理的安全边界。
• 越狱/root检测：用expo-device的Device.isJailbroken检测设备状态，若检测到越狱/root，强制用户重新登录，避免私钥泄露。
• 令牌失效主动通知：服务端可提供令牌失效推送接口，当用户在其他设备登录时，主动通知旧设备清除令牌，强制重新验证。

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