前端使用RefreshToken纯粹是在瞎搞

一、 什么是Refresh Token

说到 Refresh Token， 首先要提到的是 OAuth2.0 以及 Access Token:

Access Token 和 Refresh Token 都是 OAuth2.0 协议在 服务端 进行传输的 身份令牌, 其中有如下区别：

• Access Token

  该令牌为身份校验时使用的令牌，一般有效时间较短。每次网络请求会带上这个令牌，中间人攻击导致令牌泄露风险较大。

• Refresh Token

  该令牌为 Access Token 到期后用来刷新一个新 Access Token 的刷新令牌， 有效时间一般很长，只在刷新令牌时传输，中间人攻击时泄露风险较小。

关于以上几个名词，你可以仔细阅读并理解 Oauth2.0 RFC6749.

二、 前端不使用Refresh Token的理由

其实我看了很多篇关于在前端使用 Refresh Token 的文章了， 我们先不管为什么 OAuth2.0 的这些本该出现在服务端的东西为什么跑到了客户端上来，就当只是一些不分服务端客户端的思维来理解， 我尝试了很多次来说服自己前端使用 Refresh Token， 但都被自己一一否定了

• 身份过期后无需输入账号密码登录即可继续使用

直接让后端将身份令牌有效期改长一些不就好了吗？用户体验不就好了吗？我知道会有人说 “增大了令牌泄露和暴力破解的风险”。

• 使用 Refresh Token 可以降低中间人攻击泄露身份令牌的风险？

SSL 干什么吃的， 怎么还被中间人攻击了？ 都被抓包了， 啥Token都白搭了啊。 而且被中间人攻击的可能性还没被 XSS CSRF 的可能性高， 两个身份令牌在登录后都会被存储在本地， 如 “为了降低中间人攻击泄露风险”， 存 Cookies 肯定是不行的， 只能存储到 localStorage 或者 sessionStorage 等前端的数据存储区域中， 但只要能被 XSS/CSRF, 存哪都白搭了。

三、 前端如何降低身份令牌泄露的风险还保持很好的用户体验

1. 后端将身份令牌的有效期设置长一些，避免过期就弹登录影响用户体验；
2. 避免被 XSS CSRF 攻击，降低身份令牌被第三方恶意读取的风险；
3. 前端存储令牌和读取令牌进行一些混淆方式的编解码，增大被第三方恶意读取时能正常使用的风险；
4. 定期修改混淆方式，增加编解码的复杂度，降低第三方攻击的兴趣
5. 提高用户身份安全性验证，如异地登录、常用设备、行为判断等与身份令牌关联

四、That's all

像我之前说过的一样，“前端加解密，脱裤子放屁”， 但也会有一些特殊情况， 比如 放屁崩出屎。

Web安全是门比开发可要复杂得多的方向，可比开发要好玩多了。

前端不要给自己加戏，加也请正确的加 毕竟 他说：

就这样。