jwt 和传统的 session、cookie 的争议

2020-06-06 17:38:09 +08:00
 zw1234

jwt 和传统的 session 、cookie 有啥优缺点,token 未来是否会取代 session 、cookie ?

请发表你的观点

5560 次点击
所在节点    程序员
17 条回复
butterf1y
2020-06-06 17:40:00 +08:00
TimPeake
2020-06-06 17:49:41 +08:00
楼主我告诉你个技巧 这种话题 ,要用引战的形式,直接标题定死了:"jwt 才是未来主流,吊打 cookie"。诸如此类。
十分钟后,长篇大论回复 99+
lhx2008
2020-06-06 17:51:00 +08:00
jwt 适合安全性不高,或者鉴权功能小且固定的业务。
chen1164162915
2020-06-06 17:53:20 +08:00
JWT 注销 token 是个难题
用 redis 或者数据库就脱离 JWT 的初衷了
tomczhen
2020-06-06 18:03:47 +08:00
无非就是 server side 或者 client side,然后实现不同,细节不同,偏向不同。
ericls
2020-06-06 18:24:20 +08:00
没啥区别 一般面向用户的服务还是不会把所有用户数据存在 token 里。

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


你把 session key 放在 authentication header 他是 session key 还是 token?
zw1234
2020-06-06 18:32:31 +08:00
@TimPeake 学习了,佩服佩服
also24
2020-06-06 19:55:19 +08:00
@sriidtied #1
哈哈哈哈我也想说
nvkou
2020-06-06 20:21:21 +08:00
jwt 本身的问题可以通过协议解决。saml, openid connect 等有回调域检测,cros 控制等加强安全性。
对于业务来说,jwt 声明了我是谁以及一些公开信息。放隐私信息是开发者的锅。当然 jwt 也用于角色权限控制,但防篡改机制已经足够安全,客户端不验签,不向鉴权服务器查询状态才是问题。

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

隐私真不是问题,能获取 token 都是能过验证的,密码,数字证书都 行。你自己提供的信息谈何泄漏?
hantsy
2020-06-06 20:50:43 +08:00
@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 即可 )。
mreasonyang
2020-06-06 21:47:04 +08:00
小业务用哪个都行,大业务没人用这些,都是各种自定义的魔改 token 机制
wangyzj
2020-06-06 22:45:19 +08:00
哪个合适用哪个呗
各有优缺点
Austaras
2020-06-07 00:53:12 +08:00
JWT+refresh token 是最好的机制, 就是前端的复杂度有点高, 当然随便拿 rx{js, java, swift}封装一套就好
yanguango
2020-06-07 08:08:02 +08:00
AmiKara
2020-06-07 17:49:04 +08:00
还是那句老话:脱离业务谈技术都是耍流氓
tairan2006
2020-06-07 20:07:44 +08:00
从来没用过这玩意儿,都是直接用 uuid 当 token…
xuanbg
2020-06-08 03:04:27 +08:00
JWT 如果是仅用于身份认证那是极好的,但用于比较复杂的后台管理系统就不太合适。如我司的后台权限高达数千项之多,如果都放在 jwt 字符串里面,那是要死人的节奏。

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/679220

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX