@also24 拜读了你的文章，写的真棒！特别是提出 Client Side Session 和 Sever Side Session，更加精准简洁的描述了本主题中讨论的问题。在文章中，我发现 Sever Side Session 似乎得到更为广泛的支持。但为什么在国内，Client Side Session 模式特别盛行呢（使用如主题附录中 jwt 的实现）？

@zoharSoul #50 我未做过移动端开发，不知道移动端使用 session id 会比使用 token 复杂多少？但请你不要骗我。如果是真的，那这是一个考量点。

@zzzmh 关于篡改，根据上下文理解你的意思应该是破解 jwt，那确实如你所言，难以破解。但本主题并未说 jwt 容易破解，主题中所说篡改指的是修改了 token ,那么服务器用公钥便能分辨出这是改过的 token，从而实现了防篡改。

@LeeReamond @zzzmh #39 #46 超级高并发，高并发，或未来预期的高并发而选择使用无状态会话来减少服务器压力，这是一个值得进一步探讨的问题。如前回答 #37 所述，无状态性能更优（正比或指数或其它），但作为一个高并发架构，应该有具体的数据来支持。所以，能否分享一下达到何种量级后，无状态性能将显著超越有状态，或者说这将是一个制约系统响应时间的瓶颈。如果有这份数据，将很好的指导架构考量，来决定是否值得缺少有状态的优点，而拥抱无状态。

@GooGee #44 这是一篇很棒的文章，较为全面的质疑了 jwt 作为会话系统的优点。但我仍然没有明白，为何大家都在使用 jwt 作会话？

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

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

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

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

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

机智如我，开个新主题听听大家怎么看 jwt 做会话身份认证
https://www.v2ex.com/t/774127#reply23

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

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

@zoharSoul 这位兄台，其实所谓 cookie+seesion 方案，基本流程是后端生成一个 sessionID，发给前端，前端存起来，后续请求都带上这个 sessionID，实现了有状态的会话跟踪。但迫于种种安全问题，以及浏览器提供的便捷方式，如同域可带上这个 sessionID，跨域不允许； sessionID 返回后浏览器自动将其存储在 cookie 中；但是，以上是对于常规浏览器而言。既然你的是移动端 app 了，这个 sessionID 你想怎么玩就怎么玩，跟 token 使用毫无区别。

@wunonglin 这就相当于重新打造了一套 cookie+session 方案实现。

@leafre 感谢指出错误，私钥签发，公钥验证。refresh_token 、redis 黑名单确实能解决问题，但问题是需要前后端写代码去实现，而 cookie+session 方案，几乎不用写什么代码就具备这些功能。对于多端，cookie 存的只是一个 sessionID 字符串，请问支持 http 协议的端带上一个 sessionID 有啥困难，头里加 token 都没问题，带个 sessionID 就不能了？

@xuanbg 我觉得主要原因是一堆开源的快速开发平台使用了 jwt token 做无状态的身份认证，以至于带起了这股风气。而为什么这些快速开发平台选择了 jwt token,应该是前后端分离后，后端接口用 token 好调试，前端调用后端因为跨域，用 token 也方便。既然如此方便，那就这么办，至于带来的问题，如续期、token 签发时间过长导致不安全等问题，那就不考虑了，其实大部分软件也都不在乎，只要能过等保就好。至于突然 token 到期，用户强制重新登录这种体验问题，那不是问题，因为我们做的系统就几乎没人用，用也不会用很久。实在不行 token 签发时间给个几天，或者先做出来再说，后面再考虑打补丁，从无状态改成有状态，后端记录一下 token,给它续期得了。

好好的 cookie + session 方案你不用，学人家玩 token 。无状态 token 身份认证轻量是真的轻量，但弊端也不少啊。如果加入服务端续期什么，那还不如直接用 cookie + session，强行使用只不过造了个轮子。结合实际需求，选择技术方案。

源码呢？