关于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，相当于一个渐进式的。安全和性能 用户极致量共享会话后的拓展会好些。

 这种可以用在大多数应用

对于安全问题没有绝对基本的安全保证都是增加破解成本，和止损来达到减少损失。