JWT与Refresh Token双过期时移动端令牌校验报错求助

服务器时区为伦敦（GMT/UTC±0），客户端使用印度标准时间（IST，+5:30），日常运行正常。但当JWT和Refresh Token均过期时，生成有效期1小时的新Refresh Token以支持移动端数据同步时，触发报错：

Error: Cannot handle token prior to 2022-11-25T22:41:29+0530

该问题仅在移动端触发，Postman测试无异常。

JWT Payload 数据 #

{ 
  "iss": "website address", 
  "iat": 1669273766, 
  "nbf": 1669273776, 
  "exp": 1669273826, 
  "aud": "myusers", 
  "data": { 
    "id": 1, 
    "mobilenumber": "XXXXXXXXXXX", 
    "email": "XXXXX@XXX.com", 
    "deviceimeino": "XXXXXXXX", 
    "deveventid": xxxx, 
    "eventexpirydate": { 
      "date": "2022-11-24 23:59:59.000000", 
      "timezone_type": 3, 
      "timezone": "Asia/Calcutta" 
    } 
  } 
}

Refresh Token Payload 数据 #

{ 
  "iss": "website address", 
  "iat": 1669436131, 
  "nbf": 1669436141, 
  "exp": 1669439727, 
  "aud": "myusers", 
  "data": { 
    "id": 1, 
    "mobilenumber": "xxxxxx", 
    "email": "xxxx@xxx.com", 
    "deviceimeino": "xxxxxxx", 
    "deveventid": xxx, 
    "eventexpirydate": "2022-11-03 23:59:59" 
  } 
}

核心原因 #

报错本质是令牌的生效时间（nbf）或签发时间（iat）被客户端判定为晚于本地当前时间，导致JWT验证库认为令牌尚未生效。差异产生的具体场景：

1. 服务器生成令牌时用的是UTC时间戳，但移动端验证时错误地将UTC时间戳直接当作IST时间解析，或是用本地IST时间直接和UTC时间戳对比，导致时间逻辑错位。
2. 客户端系统时间存在偏差（比如慢于实际IST时间），而Postman默认使用UTC时间或自动处理时区转换，因此测试无问题。
3. 服务器生成新Refresh Token时，nbf设置为未来的UTC时间（比如服务器时间同步异常），移动端本地时间未同步到该时间点，触发校验失败。

解决步骤 #

1. 强制统一使用UTC时间处理

   • 服务器生成令牌时，确保iat、nbf、exp均为标准UTC Unix时间戳（Unix时间戳本身基于UTC，需避免服务器代码错误将伦敦本地时间转换为时间戳）。
   • 移动端验证令牌时，必须将本地IST时间转换为UTC时间，再与令牌中的UTC时间戳做对比，禁止直接用本地时间校验。

2. 校准客户端时间

   • 移动端发起请求前，添加网络时间校验逻辑，若本地时间与网络UTC时间偏差超过合理范围（如5分钟），提示用户校准系统时间后再操作。

3. 优化令牌生成逻辑

   • 检查新Refresh Token的nbf设置，避免将其设为未来的UTC时间；若需要设置生效延迟，确保延迟时间在合理范围内（如10秒内），同时客户端验证时允许少量时间偏差（配置leeway参数，比如30秒）。

4. 统一验证规则

   • 移动端JWT验证库的配置需与服务器端保持一致，包括时间校验的规则、偏差容忍度等，避免两端逻辑不匹配导致的异常。

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