为什么那么多 web 系统使用 jwt token 来做身份认证

[aboat365]

我个人觉得大量的 web 系统在滥用 jwt token 技术。jwt token 签发后可使用私钥来验证其是否过期和篡改，这个技术用来做下载链接、邮箱验证、或短时间内的一次性验证业务是非常好的。但如果用来做 web 系统的身份认证，那简直糟糕透顶。在真正无状态下，很难平衡签发时间和安全之间的矛盾，还有无法续期导致的用户体验问题。当然，可以打补丁，甚至变得有状态，最后解决以上问题。但是，为什么一开始不用 cookie + session 呢？想听听大家的看法。

[aboat365]

@hronro 我错了，不过懂这个意思就好。

[aboat365]

@wunonglin 有特殊需求无法满足，自定义一套当然 ok，但问题是很多用 jwt 做身份认证的系统，真的是重新造了个轮子，还不圆。

[wunonglin]

@aboat365 #22 那些就是为了用而用罢了

[xuanbg]

@leafre 不是不能，而是麻烦。现在都是 RestAPI 的服务端，哪有 session ？搞个 token 多简单，而且也方便搞分布式。

JWT 有他特定的优点，但滥用 JWT 真的不好。既然要有状态了，我自己生成一个 token 很难吗？几行代码的事，能贴合自己的需求，又不用额外引入第三方库。

[zoharSoul]

@aboat365 #19 那既然毫无关系, 不就是 token 方案了? 无非是 token 是 jwt 还是自己造轮子, 还是 sessionid,
那么 jwt 比起 sessionid 多携带点信息他不香吗?

[xuanbg]

@aboat365 这种 token 的作用确实是和 sessionId 一样的。无非就是怎么叫的问题，就不要纠结了。

[FreeEx]

因为有 80%的人是跟风用的，根本不了解其中利弊。

[aboat365]

@zoharSoul 无状态 jwt 对比有状态的 cookie + session，整体代码量自然是前者少，而且看起来简单，但后者是作为标准具有广泛的实现，实际使用几乎不用写什么代码（开发者甚至不需理解其原理，现成的实现也能工作的很好）。而 jwt 即使再简单，前后端也是要写代码的，而且如果无状态 jwt 不能满足你的需求，甚至要写很多代码，所以才说很多使用 jwt 的开发者只是在重新造轮子，还造不圆。 对于 token 中可以多携带信息，这不是什么优点，虽然大家 wifi 千兆，手机都用上 5G 了，但我为啥非得多弄点信息在每次请求中传来传去，jwt 是被迫无奈。

[aboat365]

@xuanbg 方便分布式还真是 jwt 的优点，每个系统都配置一样的密钥，然后签出去的 token ,大家都能验证。但这个优点，cookie + session 也是有非常成熟的解决方案，一个 session 共享即可。既然业务做得那么大了，都搞分布式了，恐怕无状态的 jwt 方案都不一定能满足需求了。所以，何不用 cookie + session 方案，现成的、成熟的、历经考验的、不用写代码的。

[CODEWEA]

1 、为了写简历
2 、前后端分离，前端组件生命周期一体化用 jwt 很方便

[xcstream]

为了解决 服务器超过 1000 的话 共享的 redis 压力大吧

[crab]

app 因素

[LeeReamond]

你的主题里的 jwt 常规用法根本是错的，可见 lz 没有 jwt 生产部署经验，自然会有疑问。jwt 无状态天生与容器和集群结合，为了附带业务状态，通常用黑名单代替白名单的方式，在高并发数下比 session 方案节约一个数量级以上的资源，你把 jwt 就当成 sessionid 在用，当然会产生为什么要有 jwt 的疑问

[Junzhou]

@emeab session 做横向扩展比较麻烦，比较依赖于特定服务器。如果多个服务器间共享 session 就更麻烦了

[aboat365]

@xcstream 没错，无状态 jwt 方案性能更优，但这就变成有状态和无状态会话身份认证的对比了（上千服务器的 web 服务，就不要考虑哪个方案代码多少的问题了，重新造轮子不过是几个程序员几天 996 而已，不费什么力气）。既然讨论有状态无状态，其中必然各有长短，那就看具体需求了，在满足需求的情况下，自然选性能高的方案，毕竟服务器不便宜。

[micean]

那得看身份验证是不是中心化的
令牌续期的话，自然也还是 oauth 的那套了

[aboat365]

@LeeReamond 你看的真准，我真没有 jwt 生产部署经验，甚至没有接触过什么高并发。诚然，无状态比有状态性能更佳，这是因不同方案侧重点不同造成，特别是随着并发量增大，这个差距应该成正比或指数拉大（我真的没有这方面的经验和具体测试数据，如有错，请指正并见谅）。但性能再好，也是要为真实需求而服务。如层主所言，无状态再加黑名单可满足层主系统业务需求，且是高并发服务，相对有状态能减少不少服务器钱的情况下，自然无状态方案佳。但如果只是一些微小服务，为什么那么多也用无状态 jwt 呢？而且发现不少开源软件和技术方案文章，把无状态 jwt 做成了有状态 jwt，这又何解？

[aboat365]

@Junzhou session 共享在各个 web 服务器中应该都有比较成熟的方案，而且基本不用写代码，所以，比起写代码实现无状态 jwt，这一点都不麻烦。

[LeeReamond]

@aboat365 一般合理的框架开发，不是引擎层面的，单纯讨论框架问题，一般都有集成的鉴权方案，因为太过常见，所以合理的解释就是企业各自有集成方案。毕竟部署实际上只需要对接一个分发服务而已，无论多大规模的服务，既然永远不会导致 performance 变差，同时又不需要多写代码，为什么不用呢，如果选 session，即使有万分之一的可能性这个项目做大了，日活上去了，难道到时候再改成可横向扩展的鉴权系统？

[labulaka521]

jwt 仔路过，写了一些 web 都是 jwt