jwt 和传统的 session、cookie 的争议

/t/656457

楼主我告诉你个技巧 这种话题 ，要用引战的形式，直接标题定死了："jwt 才是未来主流，吊打 cookie"。诸如此类。
十分钟后，长篇大论回复 99+

jwt 适合安全性不高，或者鉴权功能小且固定的业务。

JWT 注销 token 是个难题
用 redis 或者数据库就脱离 JWT 的初衷了

无非就是 server side 或者 client side，然后实现不同，细节不同，偏向不同。

没啥区别 一般面向用户的服务还是不会把所有用户数据存在 token 里。

就当是同一个东西放在了 http headers 的不同地方。


你把 session key 放在 authentication header 他是 session key 还是 token?

@TimPeake 学习了，佩服佩服

@sriidtied #1
哈哈哈哈我也想说

jwt 本身的问题可以通过协议解决。saml, openid connect 等有回调域检测，cros 控制等加强安全性。
对于业务来说，jwt 声明了我是谁以及一些公开信息。放隐私信息是开发者的锅。当然 jwt 也用于角色权限控制，但防篡改机制已经足够安全，客户端不验签，不向鉴权服务器查询状态才是问题。

jwt 的好处是可以通过 refresh token 刷新，由客户端自行判断。在特定场景还能实现离线使用。

隐私真不是问题，能获取 token 都是能过验证的，密码，数字证书都 行。你自己提供的信息谈何泄漏？

@ericls

Token 这东西本身有透明和不透明之分，JWT 是种典型透明的 Token，可以直接拿到用户基本信息，比如用户，scopes/roles 等，用于 API 权限判断。但安全性还是有保障，由服务器生成，其密钥或者 SecretKey 是在服务器，JWT Token 信息无法篡改。

不透明的 Token 在服务器上还需要额外一步从 IDM 上取得用户信息。

Spring Session 抽象了 HttpSession 概念， 支持用 Redis，Jdbc，Mongo 等实现，也可以通过 header 传递 Session 。每次传递到服务器从 Session Repository 中恢复 Session 用户安全信息，构建 SecurityContext 。

https://github.com/hantsy/spring-microservice-sample#secures-microservice

个人觉得 Spring Session 操作性上高于纯 JWT Token 的方式，它可以显式 Logout （调用 Sesision 的 invalidate 即可 ）。

小业务用哪个都行，大业务没人用这些，都是各种自定义的魔改 token 机制

哪个合适用哪个呗
各有优缺点

JWT+refresh token 是最好的机制, 就是前端的复杂度有点高, 当然随便拿 rx{js, java, swift}封装一套就好

还是那句老话：脱离业务谈技术都是耍流氓

从来没用过这玩意儿，都是直接用 uuid 当 token…

JWT 如果是仅用于身份认证那是极好的，但用于比较复杂的后台管理系统就不太合适。如我司的后台权限高达数千项之多，如果都放在 jwt 字符串里面，那是要死人的节奏。

所以我司系统发给用户的 token 就是一个 base64 编码后 116 位长度的字符串。解码后就是：{"id":"b016b5a2bd0147c897246d376c79f668","secret":"a4fa0f2d7c65437da86e5efab2837824"}这样的简单结构。授权信息在服务端的 token 里面，服务端 token 存在 redis 上面。把一个 token 一分为二，就像古代的虎符。用户只要拿能够代表其身份的一半就行了，其他数据反正只需要在服务端验证身份之后才会用到，就不需要给用户了。