客户端请求刷新仍有效的access token时应如何正确处理？

首先明确前提：所有刷新请求的第一步永远是先校验携带的refresh token合法性——必须未吊销、和请求方的客户端ID、所属用户完全匹配，校验不通过直接返回401状态码，和access token是否过期无关。

下面说具体的判断逻辑，先列不推荐的做法及问题：

• 不推荐「只要收到刷新请求就无条件签发新access token」：这种做法会导致token签发量无意义暴涨，一旦客户端出现逻辑bug循环调用刷新接口，会平白产生大量冗余有效token；如果没有配套旧token作废逻辑，会同时存在多个有效access token，大幅提升token泄露后的安全风险。
• 不推荐硬编码固定时间阈值（比如剩余有效期大于1小时返回旧token、小于1小时发新token）：这种逻辑适配性极差，如果你给access token配的总有效期是15分钟，1小时的阈值会导致所有刷新请求都直接签发新token，阈值规则完全失效；如果总有效期是7天，1小时的阈值又会过于宽松，客户端拿到旧token之后很快又会进入临期状态，频繁触发刷新。

推荐的通用实现方案 #

采用比例阈值+最小临期窗口兜底的判断规则，两个阈值都做成可配置项，不要硬编码：

1. 计算当前access token的剩余有效期占自身总有效期的比例，常规场景可以把比例阈值设为20%：
   • 如果剩余有效期占比高于阈值，且剩余时长大于你设置的最小临期窗口，直接返回原有旧access token，不执行新token签发逻辑
   • 如果剩余有效期占比低于阈值，直接签发新的access token
2. 加最小临期窗口兜底规则：不管剩余占比是多少，只要access token剩余有效期小于兜底窗口（常规设为5分钟即可），直接签发新token，适配短有效期token的场景。

举几个实际场景的判断结果：

• 总有效期24小时的access token，当前剩余8小时：剩余占比约33%>20%，且剩余时长远大于5分钟，直接返回旧token
• 总有效期24小时的access token，当前剩余2小时：剩余占比约8%<20%，签发新token
• 总有效期15分钟的access token，当前剩余4分钟：剩余占比约27%>20%，但剩余时长小于5分钟的兜底窗口，直接签发新token

可选安全优化项 #

• 签发新access token时建议同步做refresh token轮转：同步返回新的refresh token，将本次请求携带的旧refresh token加入吊销列表，避免refresh token长期固定带来的泄露风险
• 安全等级要求高的场景，可以在签发新token后，将旧access token的唯一标识（比如JWT的jti字段）提前加入失效列表，保证同一时间单个用户/客户端只有一个有效access token，缩小token泄露后的影响范围
• 阈值可以根据业务场景灵活调整：面向公网的高安全要求场景可以把比例阈值调到30%、兜底窗口调到10分钟；内部服务低风险场景可以把比例阈值降到10%，减少token签发的性能开销。

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