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

 这种可以用在大多数应用

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

————————

方案一:

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

 这种可以用在大多数应用

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