一、 什么是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, 存哪都白搭了。
三、 前端如何降低身份令牌泄露的风险还保持很好的用户体验
- 后端将身份令牌的有效期设置长一些,避免过期就弹登录影响用户体验;
- 避免被 XSS CSRF 攻击,降低身份令牌被第三方恶意读取的风险;
- 前端存储令牌和读取令牌进行一些混淆方式的编解码,增大被第三方恶意读取时能正常使用的风险;
- 定期修改混淆方式,增加编解码的复杂度,降低第三方攻击的兴趣
- 提高用户身份安全性验证,如异地登录、常用设备、行为判断等与身份令牌关联
四、That's all
像我之前说过的一样,“前端加解密,脱裤子放屁”, 但也会有一些特殊情况, 比如 放屁崩出屎。
Web安全是门比开发可要复杂得多的方向,可比开发要好玩多了。
前端不要给自己加戏,加也请正确的加 毕竟 他说:
就这样。