关于Jwt的一些思考

标签：客户端   很多   有一个   令牌   使用   模式   ESS   com   设置   

在使用jwt的过程中发现了两个问题续期和退出的问题。

续期

因为jwt的token在签发之后是有过期时间的，所以就存在管理这个过期时间的问题。我看网上有提出解决方案的大致有下面几个

• 每次更新过期时间，跟session一样，每次请求的时候都会去更新下token过期时间.但是对于jwt来说，更新过期时间就意味着jwt的token会变,那么前端就需要每个请求都去保存一次新的token。这样使得前端的工作变的复杂起来。而且这样做的话，会存在多个令牌同时有效，可能会引起一些安全问题。
• 还有一个就是每隔一段时间去更新一次token。这种做法也是很多人采用的一种。比如：token过期时间是一个小时。预设每五十五分钟去更新token。这种模式也是需要前端去配合完成的。

退出

因为token在签发之后在一段时间内是一直有效的，那么这种情况，我们怎么去管理登出呢？

• 简单的方式就是客户端直接删除token。但是这样的话，如果token泄露了也是不安全的。
• 有人提出退出的时候将token存放在redis中,过期时间设置为跟token的时候一样。当用户在次用旧的token访问的时候，如果发现redis中存在token，那么提示token过期。

对于续期的话，个人觉得第二种方案是比较好的一种方案。而退出的话，如果不考虑泄露的问题，那么第一种方案是比较好的一种方案。但是如果做SSO的话可能第二种方案是比较好的一种，但是在用到了redis之后就违背了jwt的设计初衷，需要与数据库交互。
其实个人觉得，jwt的加密方式结合redis这种也是可以采用的。毕竟这些都是为了解决问题。当利用到redis之后，我们就可以将jwt扩展下。在payload部分加载一个生成的refresh token ，这个refresh token也是有过期时间的，我们需要将这个refresh token存放在redis中。这样的话，我们就可以把jwt的过期时间放在这个refresh token中维护。续期也就是维护这个refresh token的过期时间，退出的话 也就是删除这个refresh token就可以了。
其实这样的话就跟传统的token验证一样了，也就是外层加了一个jwt的验证。
可能是我对于这方面了解的比较少，不能想到什么有效的方案。这些都是自己对jwt的一些理解。如果哪位大佬有更好的方案，希望赐教。感谢

原文地址：https://segmentfault.com/a/1190000016650479

关于Jwt的一些思考

标签：客户端   很多   有一个   令牌   使用   模式   ESS   com   设置   

原文地址：https://www.cnblogs.com/lalalagq/p/9964973.html