卧槽， jwt 这种认证方式竟然不需要在服务器本地存信息？

[51300520]

以往我登录验证一直是生成 token，发给客户端，自己存数据库，下次客户端发来我从数据库里面取出对比。

刚调试一个 golang 的登录程序，我就纳闷，他生成一个 token 返回给客户端，我重启服务程序后该 token 竟然还能准确认证。该 token 我并没有在服务器上落地，重启后它是怎么还能继续验证的？　我以为是不是 jwt 包在哪里偷偷落地了，于是单步仔细检查了一番，发现没有。　于是 google,竟然发现这玩意不需要落地就就能一直验证。　太ＴＭ神奇了。。。。

顺便问句，这玩意可靠吗？容易被破解不？如果可靠，那以后登录验证就用它了

[AlphaTr]

单点登录的话，用非对称加密，业务方用公钥验证签名就行，私钥保存在认证服务器；黑名单这种要求不严格的话，定期去认证服务器拉黑名单列表就行

[dcalsky]

@yamedie token 放 header 里再上 ssl。如果这也能丢了那密码也能丢。主流做法是在后端存 refresh token 来刷新 access token （上文的 token ）。这样能防止丢失 access token 被长期使用。

[Zzdex]

.........

[limuyan44]

https://jwt.io/introduction/ 看完对 jwt 就没那么多疑问了，jwt 本身的实现是很简陋的，如果使用 jwt 根据具体的场景更多是配合其他的策略，毕竟说白了 jwt 只是解决了数据信任的问题。

[chinvo]

jwt 的 payload 放一个服务器生成的字符串，验证时额外增加对 payload 的验证，“吊销”这个字符串就能达成“吊销” jwt 的目的

[loading]

@chinvo 既然服务器都已经要存 playload 了，不如退回去 session 方式。

[cheneydog]

有好处也有坏处，淡定。

[yamedie]

@loading 在服务器水平扩展时需要多个服务器之间会话保持来共享 session，我个人感觉这种技术是很过时的

[loading]

@yamedie 所以我说没有银弹，jwt 如果安全问题需要考虑，例如要屏蔽某个 token，那么就要增加标记，然后就会遇到 session 的共享问题。

[mingmeng]

jwt 好处是很轻，但是实际对于业务安全来说还是要做很多包装的～

[danmu17]

用 jwt 做 session token 属于安全漏洞的范畴了