页面刷新时是否需生成新Access Token并失效Refresh Token？

1. 关闭标签页后，之前仍有效的access-token是否无法被使用？ #

• 不是的。只要access-token还在有效期内，理论上任何人拿到它都能用来调用API——你把它存在内存里，关闭标签页只是前端丢失了这个token，但服务器端并没有标记它失效。如果这个token被提前窃取（比如通过XSS攻击），即使你关了标签页，攻击者依然能用它直到过期。

2. 对于未使用但仍有效的access-token，是否需要对其进行失效处理？ #

• 一般不需要特意处理，核心原因是access-token的有效期本来就设得很短（比如15-30分钟）。短有效期本身就是一种安全机制，就算有未使用的有效token，它很快就会自动过期，风险窗口很小。如果要强行失效，你得做token黑名单，但这会增加服务器的存储和校验成本，得不偿失。

3. 是不是因为access-token有效期较短，所以可以在每次页面刷新时生成多个，无需在意数量？ #

• 没错。短有效期的access-token就是设计来高频生成的，每次刷新页面调用/refresh-token拿新的access-token完全没问题。只要你的/refresh-token接口做了正确的校验（比如验证refresh-token的有效性），多生成几个access-token不会有太大安全问题，毕竟它们很快就会过期。

4. refresh-token轮换（使用后失效）机制是否强烈推荐？ #

• 非常推荐。这个机制能大幅降低refresh-token泄露后的风险：如果攻击者拿到了旧的refresh-token，它已经被用过一次并失效，就没法再用来换access-token了。尤其是当你的refresh-token有效期较长（比如几天）时，轮换机制是必须的安全措施。

5. 是否需要将用户的refresh-token存储在数据库中，以便每次请求新access-token时失效旧的？ #

• 是的，必须存在数据库里。因为要实现refresh-token轮换，你得能验证当前提交的refresh-token是不是用户当前有效的那一个，并且在生成新的refresh-token后，把旧的标记为失效。

6. 是仅存储当前有效的refresh-token并失效旧的（如何实现），还是需要保存所有refresh-token列表？ #

• 只需要存储用户当前有效的那一个refresh-token就够了，不需要保存所有历史列表。实现方式很简单：
  • 用户登录时，生成第一个refresh-token，存在数据库（关联用户ID），同时设置到httpOnly cookie里。
  • 当用户调用/refresh-token时，先校验cookie里的refresh-token是否和数据库中存储的一致：
    • 如果一致，生成新的refresh-token，更新数据库中该用户的refresh-token为新值，同时把新的refresh-token设置到cookie里，旧的自动失效。
    • 如果不一致，直接拒绝请求（说明这个refresh-token已经被用过或者是伪造的）。
  • 这种方式既节省存储，又能有效实现轮换机制，避免旧refresh-token被重复使用。

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