标签：请求 登录 用户 refresh 身份验证 token 刷新

基于Token的身份验证的基本过程如下:

1.用户通过用户名和密码发送请求。

2.服务器端程序验证。

3.服务器端程序返回一个带签名的token给客户端。

4.客户端储存token,并且每次访问都携带token到服务器端的。

5.服务端验证token，校验成功则返回请求数据，校验失败则返回错误码跳转重新登录。

使用refresh token的身份验证操作：

但是如果用户在正常操作的过程中，token过期失效了，要求用户重新登录，对用户的体验会很不好。

使用refresh token，可以避免频繁的读写操作。这种方案中，服务端不需要刷新 token 的过期时间，一旦 token 过期，就反馈给前端，前端使用 refresh token申请一个全新 token 继续使用。大大减少了用户重新登录的操作。当然 refresh token也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间（15天）。

要点：refresh_token必须保存在客户端的服务器上，调用refresh_token的时候一定是从服务器到服务器的访问。

refresh_token多次刷新问题：

当token超时refresh_token未超时，调用refresh_token刷新token时，如果有新的请求，此时也会再次调用refresh_token刷新，产生多次刷新问题。

设置刷新状态处理多次刷新问题，设置刷新状态变量，当调用refresh_token刷新时，更改刷新变量，其他请求此时就会停止调用刷新状态。但是1却会产生新的问题，等待token刷新时产生的请求处理问题。

等待token刷新时产生的请求如果直接不处理或者让用户再次操作，都会对用户的使用产生不好的体验，可以采用存储请求队列的方式，等待token刷新时产生的请求存储到队列中，当token刷新完毕再重新执行。

请求存储的方式虽然解决了等待token刷新时产生的请求处理问题。但是却过于麻烦，还会影响响应时间。

最终解决方案

每次请求时服务器都对token的有效时间进行判断，当token快要过期时，生成新的token返回，记录刷新时间，短时间内只能刷新一次token，这样就解决了多次刷新的问题。

同时由于token的校验是通过token中的有效时间信息来判断，所以旧的token也能持续一段时间使用，就不会产生请求等待问题。

要点：

什么时间判断要生成新的token：推荐token有效时间的一半。至于为什么要设置这么早，这里引入“活跃用户”的概念。

简单来说用户的上一次操作不超过我们规定的时间，那么这个用户就是活跃用户。什么时候需要让用户重新登录和什么时候需要刷新token？一般都是希望活跃用户刷新token，不活跃用户重新登录。

当用户超过token时间未发送新请求，可以认为是不活跃用户，此时再发送请求就会跳转到重新登录，token有效时间可以设长一些，用户也能更好接受。

如果设置token刷新时间太晚，例如token有效时间1小时，50分设为刷新时间的话。当用户一小时49分最后一次操作，那么11分钟后他就需要重新登录才能操作，所以尽量不要设得太晚。

标签：请求,登录,用户,refresh,身份验证,token,刷新
来源： https://blog.csdn.net/m0_55141616/article/details/121111973

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。