关于JWT中Refresh Token作用及安全性的技术问询

为什么用短期Access Token + 长期Refresh Token，而非直接用长期Token？ #

• 风险可控性：Access Token是直接调用业务接口、访问资源的凭证，短期过期的话，就算被盗，攻击者能滥用的时间窗口非常有限，损失能降到最低。如果用长期有效的Access Token，一旦泄露，攻击者可以长时间冒用身份操作，直到Token过期，风险极高。
• 权限隔离：Refresh Token的唯一作用就是获取新的Access Token，它本身不能直接访问任何业务资源。就算Refresh Token泄露，攻击者最多只能拿到新的Access Token，而服务器可以通过异常检测（比如异地请求、频繁换Token）触发安全机制，比如要求二次验证，直接失效对应的Refresh Token，及时阻断攻击。
• 灵活的权限调整：如果业务需要调整用户权限，短期Access Token过期后，新生成的Token会自动应用新权限；如果用长期Token，要么等它过期，要么得维护庞大的Token黑名单，成本高且复杂。

Refresh Token同样容易被盗取吗？ #

是的，Refresh Token也存在被盗风险，但相比Access Token，它的安全风险更低，防护手段更多：

• 存储更安全：通常Refresh Token会存在开启了HttpOnly和Secure属性的Cookie中，这种Cookie无法被前端JS读取，能有效避免XSS攻击窃取；而Access Token一般存在localStorage或内存中，更容易被XSS盯上。
• 权限范围窄：就算Refresh Token被盗，攻击者无法直接用它访问业务接口，必须先去换Access Token，这个过程会留下请求记录，服务器可以通过IP、设备指纹等信息识别异常，及时拦截。
• 可主动撤销：服务器端可以维护Refresh Token的存储（比如存在数据库或Redis中），一旦用户登出、修改密码、账号异常，能立刻将对应的Refresh Token标记为失效；而Access Token是无状态的，除非过期，否则无法主动撤销（虽然也能做黑名单，但短期Token的生命周期短，黑名单的维护成本可以忽略）。

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