@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，强行使用只不过造了个轮子。结合实际需求，选择技术方案。

源码呢？

支持

为什么大家都这么厉害