token过期后续签问题

Question

老师好，有两个问题请教，
1.关于token过期如何续签老师能给个方案吗？续签方式和客户端使用便捷性之间如何平衡？
2.看到老师在各种方法上都抛出了异常，这种方式是否在正式项目中可行？
3.JWT Claims本身定义了一些标准参数，如iss、sub、aud、exp、iat等，是否有必要再定义key

Answer 1

张勤一 2021-08-04 19:49:13

同学你好：

    你这里提出的问题还是非常好的，可以看出来是经过思考的；但是，小火鸡，我不得不说，这是三个问题，不是两个。我来回复下：

    （1）Token 续期是个非常重要而且基础的功能，它的实现思想是非常简单的，且不需要 Client 的参与；Client 的每一次请求都需要去续期是最稳妥的做法，可以重新生成一个 Token，或者是刷新原来 Token 中的过期时间；

    （2）这当然是可用的，我抛出了异常有什么问题吗？这只是编码的一种方式，并不会影响功能的正常运行，如果你觉得没有必要，或者是不好，那么，修改成你想要的就可以了；

    （3）确实，JWT 定义了一些标准参数，不过，添加或者不添加 key 似乎问题也不大，反正解析的过程都是你来控制的，那么，放在哪个参数里不可以呢？

• 提问者 andy0503 #1

  老师好：
  1）如果每次客户端调用都重新生成token那这个网络IO和开发成本（也就是我说的易用性）是非常高的，另外如果是刷新过期时间那本质上是重新签发了一个token，对于非cookie存储的调用端（比如APP用sqllite或内存）来说还需要单独对token刷新维护，这在多项目组间开发接入来说非常不友好，另外像token失效（比如用户同时在两个端登录但在一端修改了密码）有没有什么解决方案。
  2）抛异常当然是没问题的，我是想说在真实项目中是否也会这样大量的往外抛异常，因为我在项目中都是尽量缩小错误范围，非中断性错误都不会抛异常。另外大量的异常栈信息对内存也是一种消耗，不知道是不是我有认知误区

• qq_兰桨_0 回复 提问者 andy0503 #2

  你好，对于问题1，我记得有个比较古老的方法，下发两个过期时间，一个快，一个慢，快的那个用于判断刷新慢的。这样技能不重复生成token也能解决token续期的问题。