基于JWT认证的REST API为什么需要refresh token，不能仅用其发起所有请求？

• 缩小CSRF攻击的影响范围 #

  httpOnly cookie可以规避XSS窃取，但无法防御CSRF攻击。如果将长有效期refresh token作为所有接口的认证凭证，恶意站点构造的钓鱼请求会被浏览器自动携带对应cookie，直接完成认证执行高危操作（比如账号信息修改、数据删除）。
  而常规双token流程中，普通业务接口只校验放在自定义请求头、存储在内存中的access token，CSRF攻击无法读取到内存里的token值，哪怕请求自动携带了refresh token也无法通过业务接口的认证。只有专门的token刷新接口才会校验refresh token，仅需要对这单个接口做严格的CSRF防护（比如配置SameSite Cookie、校验请求来源）即可，风险面被大幅收窄。

• 降低凭证泄露后的危害时长 #

  长有效期凭证一旦泄露（比如用户设备被植入恶意程序读取本地Cookie、服务器日志泄露Cookie字段），攻击者可以在凭证有效期内持续访问用户账号，往往需要全量作废所有用户凭证才能彻底止损，会造成大面积用户被迫下线。
  而短有效期的access token泄露后最长可用时间通常只有15~30分钟，危害可控；就算refresh token泄露，也可以单独对该用户的refresh token做拉黑处理，不需要影响其他用户，攻击者拿到refresh token也只能生成有限几个可用的access token，拉黑后就无法继续获取新的凭证。

• 支持权限快速生效 #

  如果只使用长有效期refresh token，用户权限变更（比如管理员权限回收、会员到期）后，权限更新需要等到凭证过期才会生效，滞后性可达数天甚至数月。而短有效期access token刷新时会自动拉取最新的用户权限，最多半小时内就能完成权限更新，不需要强制用户重新登录。

另外补充：HTTPS传输也存在极端泄露风险（比如用户设备安装了恶意根证书、代理节点被攻破），长期凭证在每次请求中都被传输，暴露频次越高被截获的概率越大，用短有效期access token做日常认证，就是把高频暴露的凭证换成低危害的短期凭证，最大化降低风险。 #

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