关于jwt 续签的问题

方案一：
　　   就一个token(access_token)，续签就是token到期的时间设置长一点（比如24小时）这种可能有安全问题，安全性要求高的不考虑这种，但简单一般小项目可以用个人博客企业官网之类
方案二：
　　   一个token 时间可以短些比如30分钟，当验证token过期后，客户端请求刷新token的接口生成新的 但为了保证token被盗用及时止损需要刷新token接口做限制，比如一个ip或者一个用户能在一天时间内只能48次 超过或者等于就重新授权登录
优点就是能够及时控制止损，可以用在一般的app（减少api暴露但也可解包）和网站，但安全系数依然不是很高。

方案三：
　　   两个token （access_token和refresh_token）。

首先服务端生成access_token（比如30分钟）和refresh_token（24小时然后存在到客户端，access_token放在cookie 同时设置httponly ，refresh_token 则放在客户端的localstorage里。

放在localstorage 是减少传输 减少中间攻击之类的拦截到，至于放在localstorage可能被xss，但access_token xss拿不到，可能被中间人攻击拿到，但成增加了破解的成本。

这都是增加了破解的成本来保证安全的。

当然还是可能被破解，所以 还可以在服务端增加refresh_token黑名单（这要定期清理了，不然有性能问题）。这一步多数应用都可以保证了，可以考虑，实现也容易。

在此还可以用redis来存refresh_token，但客户端就不要存了，access_token做键（当然可以用UUID都行，不过需要存在载体Payload中）

refresh_token做值存到redis，设置过期时间，到期redis了就没有了。不过这种就不符合jwt规范了，但要也要比传统的cookie-session拓展要好不少者也是大多数人用jwt来实现会话

相当于一个渐进式的。安全和性能 用户极致量共享会话后的拓展会好些。

这种就是安全性性高的项目（一般就是涉及到钱了）

更加安全可能会给客户端在服务端在加个中间层来实现这种一般项目也用不到，也不是个人就能完成的。
 
对于安全问题没有绝对基本的安全保证都是增加破解成本，和止损来达到减少损失。