刷新 token 之后，旧的 token 会立即失效，应该如何解决？

既然刷新了 token , 旧的 token 肯定要失效，如果没有失效，就不应该刷新，不然旧的 token 不失效，岂不是没用了

@OneStep 刷新 token 和旧 token 应该有一个过渡时间吧

刷新 token 一般是 token 过期才会去刷新吧？如果 token 没有失效，主动获取新的 token 的情况，假如我连续刷新几次，几次 token 都有过渡时间？而且刷新 token 以后你已经拿到最新且有效的 token 了，以前的 token 还有什么存在意义呐？

举个最简单的例子，把 token 想象成密码，已经修改了密码，以前的密码不是立即失效么？

@OneStep 不不不，你有没有想过并发的情况，我现在是把刷新 token 写在首次载入全局布局上的时候刷新 token，这个时候页面还有其他 ajax 请求，其他请求有可能提示 token 过期了，或者说，刷新 token，这一步骤应该写在哪里比较合适呢？

@wangjiu 首次载入应该是获取 token, 而不是刷新 token。我没太理解你说的并发？假如你用的是 OAuth 2.0 这种 API 认证方式，token 是颁发给客户端的，或者说同一个用户在不同地方同时登陆获取的 token, 他们的 token 都是获取的，而不是刷新的。获取到的 token 多个客户端或者同一个用户不同地方登录的都能使用.

刷新 token 一般在后端或者 app 之类发送请求，但是 api 认证 token 失效后抛出一个异常，然后后端或者 APP 根据这个异常来主动刷新 token

我觉得你可以在首次载入的时候全局判断是否存在 token, 如果存在 token 则判断是否过期，需要刷新，如果不存在就获取 token

文档里面有个 Dingo API 中文文档 , api 认证我昨天刚翻译好，你可以去看看

@OneStep 例如，我在第一次全局载入的时候，刷新 token 和获取用户资料（同时发出），那么这时候，有可能因为 token 被刷新了，所以用户资料获取的 token 就过期了

@wangjiu 我上面已经说的很清楚了

第一次载入为什么要刷新 token 呐？
token 你都没获取到，你就刷新？？？？？？
或者说你以前缓存了 token, 你不应该是判断以前的 token 是否有效么？

而且还有一个逻辑问题，既然你刷新了 token, 不应该拿到新的 token 才去进行下一步操作么？

@OneStep 假如 A 请求发出的时候 token 还没有过期，B 请求发出的时候 token 过期了，但是因为某种原因 A 请求到达服务器的时间比 B 晚，那 A 请求就会抛出异常，然后又去请求一次服务器刷新 token 了。
像微信的 access_token，当你刷新的时候，老的 token 在 5 分钟之内还是有效的

@GerBawn 恩微信的 access_toekn 刷新后，中控服务器 会继续验证旧的 access_token5 分钟。不过微信开发有 access_token 获取次数限制。也不是动不动第一次全局载入就去刷新 token 吧。像 QQ 登录之类的，refreshtoken 后，旧的 token 都是立即失效了，refreshtoken 是更新令牌的意思，是不是可以理解为账号登录体系里面的修改密码？修改了新的密码，就密码就失效了. @wangjiu 的误区在于：刷新 token 的同时，还有一个普通请求。如果规范起来，完全用不着像微信那样搞个中继来继续验证旧的 TOKEN 吧

@OneStep 请问下，能不能根据过期时间，在 token 过期之前主动发起更新 token 呀，为什么得等到失效后才发起更新

@will_lin 可以是可以，不过如果按需刷新的方式更好一点，特别是类似微信的 access_token 有请求次数限制的接口

@GerBawn 照您所说的，假如 A 请求发出的时候 token 还没有过期，B 请求发出的时候 token 过期了，但是因为某种原因 A 请求到达服务器的时间比 B 晚，那 A 请求就会抛出异常，然后又去请求一次服务器刷新 token 了，A 请求继续去刷新一次 Token 没有问题的，让它再刷一次咯，反正 A 刷完了代表更新了 token 对吧，那下次请求就直接会带上最新的这个 A 请求刷新的 token 来了，那么会有什么问题？这不挺好的吗

@wangjiu 过期了那不是应该自动 再去刷新一次 token 吗，用户又感知不到，有什么关系

参考 jwt-auth，在 token 失效进入 blacklist 时候还可以配置在多久内这个 token 还能使用，解决高并发场景的情况。

@GerBawn 哈哈哈，他们都不懂你，因为这里面大多数人都在做服务端，客户端的痛楚他们没有想到

config 目录下的 jwt.php 文件配置里 blacklist_grace_period 参数

允许过期 token 在一定时间内访问，这个就能解决并发请求 token 失效的问题。

我的做法是在 token 失效前允许登录一次，Auth::onceUsingId() 并且新的 token 通过 setAuthenticationHeader 在 header 里响应，客户端需要获取 header 及时更新 token

顺便打下小广告 https://github.com/cyd622/laravel-api 这个是我自己参考大神们的经验，汇总起来的一个快速 API 初始化助手

安装 composer require cyd622/laravel-api

目前实现的功能：

• 统一 Response 响应处理
• 自定义异常捕获拦截处理
• Laravel Api-Resource 资源 分页返回统一响应
• jwt-auth 用户认证与无感知自动刷新
• jwt-auth 多角色认证不串号
• 单一设备登陆