Token 过期的问题

[guyskk]

目前流程是用户登录成功之后，返回一个 token 给客户端， token 过期时间为 30 分钟。请求其他 API 时客户端带上 token ，服务端依据此 token 判断是否登录。 现在问题是 token 会过期，过一段时间就要重新登录，把过期时间设长一点只能减少过期的频率，不能根本上解决问题。 所以有没有像 Session 那样，只要用户一直在线就不过期，超过一定时间不在线才会过期的库 /算法 /Demo ？

https://github.com/mattupstate/flask-jwt/isues/29
refresh token 也看了一些，感觉有点复杂

[virusdefender]

心跳包，每次增加一段时间的有效期

[Sharuru]

session 也是有过期时间的。

很简单的做法就是每次使用 token 前（你总有个方法检测 token 是否有效吧？），顺手延长一下 token 的有效期。

[bk201]

快要过期发数据包续命

[laoyur]

这个问题我也想过
似乎正面的方案就是用 refresh_token 机制，这个就是费客户端一点事而已，如果实在觉得烦
可不可以服务端自己写一个 middleware ，判断 token 快要失效时，主动颁发一个新的 token 给客户端，当然，这还是需要客户端来配合，依然烦躁……

[morewe]

每次 APP 启动登录的时候给 token 续命。

[uniquecolesmith]

jwt 解决你需求 如果你的 jwt 是有效的，只要每次更新 jwt 即可 同时 jwt 也有过过期时间 所以完全满足你 (如果不知道 搜一下)

[uniquecolesmith]

关于楼上 @laoyur 说的 之前也试过(之前微信公众号的接口也有这个属性 但是后来取消了) 但是效果不不好 一般也用不到

[DRcoding]

微信公众号的 token 是需要一个中控服务器定时请求刷新的，有效期两小时。
登录后，客户端也可以定时像服务端接口请求一个新的访问的 token 。

[Totato5749]

之前公司项目也有这问题，是在是烦躁，于是就改成很简单的，每次用到 token 的接口服务器直接给这个 token 续期。。。 也就是说如果用户一段时间没用 app ， token 才会过期

[uniquecolesmith]

仔细看 发现 LZ 也用了 jwt, jwt 很简单 是过去 token 的升级版 非常强大

[guyskk]

@uniquecolesmith
用 jwt 应该是可行的，但是看那个 issue 一直没解决，我感觉是更新 jwt 的算法卡住了，如果每次请求都更新一下 token ，会不会太频繁了。

[laoyur]

@guyskk 所以用我说的『可不可以服务端自己写一个 middleware ，判断 token 快要失效时，主动颁发一个新的 token 给客户端』这种方案开销会较小
你一个请求发到服务端，服务端是知道这个 token （当然是用 jwt 了，服务端不用额外来维护已经颁发出去的 token ）啥时候过期的，如果发现快要过期了，就主动颁发一个新的 token 过去
这种方案的话客户端逻辑最简单，就不需要主动去调用 refresh_token 接口了，不过还是需要客户端在 response 的地方统一处理一下新颁发的 token

[vghdjgh]

安全的 session 是不能无限被刷新的，所以肯定有最终过期时间，可以设置为 token 的过期时间，这样就避免刷新 token 了。
一般移动端的过期时间以月为单位， web 端一般以天为单位。

[vghdjgh]

web 端自动登录的以周为单位。
这样性能也很好的，不会频繁产生 token 。

[guyskk]

@vghdjgh
如果登录后返回一个过期时间为 1 周的 token ，一周后 token 即将过期的那段时间，如果用户正在浏览网站，一会 token 过期了，他就需要重新登录，还是会打断正常的使用。

[uniquecolesmith]

首先 相比 IO jwt 计算忽略不计 其次楼上也有人说了 写 middleware 等快过期了再更新即可

[longnight]

在缓存 /数据库某处保存键值对，纪录{token: last_visited_at}, 然后每次访问时都检查判断 /更新这个时间值，即可。
说得比较简略，以前做过这样的系统，是可行的

[klesh]

1. 客户端 token 只存简单的数据，如 userId 。永不过期，除非服务端返回 403 状态码。
2. 当 token 进来时，校验，解析出 userId ，从缓存（如 redis ）获得 userData ，若缓存存在，更新过期时间。
3. 若缓存没有命中，从数据库加载返回同时存入缓存，设置过期时间。
4. 基于安全考虑，可在 token 中再加入一个 version 字段，在第 2 步时校验该段。当改密码或其它需要将所有已登录的客户端重登时只需更新 version 字段，并清空缓存即可。

以上，客户端无需主动刷新，也无需定期更换 token ，只有在服务端声明 token 无效时抛弃即可，同时里面也不会包含太多的敏感信息（ jwt 只是 base64 编码，随手都可以解析数据出来，不应将敏感数据放在此处），数据量少 token 相对也短些，对传输也有好处；服务端可完全控制 token 的有效性，在必要的情况下可自主 revoke 已颁发的 token 。

[googlebot]

api 的 token 复杂，在 auth 2.0 里，
普通 auth token 一个小时过期，
还有一种 fresh token 基本不过期，或半年过期，用 fresh token 可以领新的 auth token ，不用输入密码，
fresh token 的申请的权限多，

[vghdjgh]

可以考虑这样一种情况： token3 天过期，然后会刷新 token ，刷新一定次数之后，不能继续刷新了（不然第三方每隔一段时间刷新一下， token 就永不过期了），这时候如果用户正在使用，一样会打断用户的。
一个方法是，把过期时间加入 token 的公开部分，客户端可以自己解析出过期时间，再通过其它 API 获得服务器时间，就可以知道什么时候过期，可以在客户端定时（ 1min ）检测，在过期前几分钟，提示“长时间未登录过，为了安全，需要重新登录”。