这是一个创建于 1304 天前的主题，其中的信息可能已经有所发展或是发生改变。
JWT 本身只适合于无状态的场景，结果现在越来越多的人要用 JWT，然后还要求能吊销 token，这样不是服务端要保存相关信息吗？那还不如直接用 cookie+session，前端端分离项目没法用的话，完全可以自己造轮子，随机生成一个 UUID 作为 token，会话保存在 redis 中。
 |
1
dqzcwxb 2021-04-29 17:29:43 +08:00
强行追新,半路掉头
|
 |
2
yejinmo 2021-04-29 17:32:54 +08:00
验证 JWT 时间戳，如过期直接失败，可以减少一次查 session 的操作
|
 |
4
kindjeff 2021-04-29 17:50:09 +08:00
有个好处是 JWT 想踢人的话做黑名单至少能比 session 的办法少存很多东西，只需要存着黑名单内的值就行
|
 |
5
kop1989 2021-04-29 17:52:28 +08:00
主要是现在互联网滥用组件的风气太盛。
仿佛只有自己写的轮子是屎山，引用一大坨第三方库、框架就不是屎山一样。 |
 |
6
acmore 2021-04-29 18:00:09 +08:00  2
除了 “无状态” 更适合讲故事之外，把 “状态” 保存在 Token 里比保存在 Redis / Memory 里要简单很多，这属于实现上的考量。而且就本质来说 JWT 没有对 “状态” 这件事任何规定和限制，其本身只是一种数据格式而已，所以在实现上甚至可以把 Session ID 放在 JWT 里，把 JWT 当 Cookie 用，这都是很正常的场景，不能算是滥用。
不过要求 Revoke Token 的话显然就又完全地回到 “有状态” 的场景中了，相当于要把 “有状态” 的东西重新发明一遍，只能说折腾万岁了。 |
 |
7
darknoll 2021-04-29 18:15:39 +08:00
token+session 不可以吗
|
 |
8
jeffwcx 2021-04-29 18:20:55 +08:00
本来就不用 jwt 做 token，有缺陷的
|
 |
9
bthulu 2021-04-29 19:46:35 +08:00
jwt 的逻辑跟 session 一模一样的, session 是服务器返回一串身份标识符, 客户端保存到本地, 后续每次调用都带上这个标识符.
jwt 也是服务器返回一串身份标识符, 客户端保存到本地, 后续每次调用都带上这个标识符. 唯一区别就是后续每次调用, jwt 时放在 header 里带过去, session 是放在 cookie 里带过去. 明明是一模一样的东西, 偏偏还要吹牛逼弄个新概念出来. 说什么 jwt 服务端不用保存状态, session 你也可以不用保存状态啊. 不用容器自动生成的 uuid 作为身份标识符, 按照 jwt 方式将用户身份标识等等数据加密后发回到 cookie 就好了. 纯粹就是重复造轮子, 面向 KPI 编程 |
 |
10
chendy 2021-04-29 19:56:40 +08:00
好奇问一下，前后端分离 cookie 不能用是什么场景？前后端走完全不一样的域名？…
|
 |
12
xuanbg 2021-04-29 21:06:23 +08:00
JWT 最大的优点是无状态，只要密钥一致就能认证。同时，最大的弱点也是无状态。所以，需要 token 有状态的场景，使用 JWT 就是滥用。那些用户信息、授权信息放在服务端不香吗？放 token 里面除了增加体积，还能有什么好处？认证的时候反正都能获取到，获取后另外放在请求头里面不好吗？至少不需要担心数据被篡改，token 也不需要加密，加解密什么的，不需要额外的运算和时间的吗？
|
 |
13
passerbytiny 2021-04-30 09:35:38 +08:00 via Android
JWT 只是个 “刀”，用得好坏取决于用它的人，不取决于它。被滥人用、被滥用，这俩应该还是有区别的吧。
建议用 JWT 之前，先上 https://jwt. io 去看一眼。JWT 的全称是 JSON Web Tokens，它只是个 Tokens，是“安全”的“认证”的“环节”的一种实现手段。把 JWT 等同于安全控制的人，非蠢即坏。 |
 |
14
kahlkn 2021-04-30 10:14:31 +08:00
以前找开源系统看源码都挺正常的，现在基本上很多搜到的，动不动就是 JWT 。 刚刚回答的另外一个 问 JWT 的，反正我是不建议 业务系统走 JWT 。 正常的 类似于 session 的 token 不香嘛，还有 分布式 session 。
有兴趣可以去看看，我就不 copy 了。 |
|
15
kahlkn 2021-04-30 10:15:04 +08:00
|
 |
16
polyang OP @kahlkn 去看了，觉得你说的挺有道理，jwt 确实应用场景挺狭窄的，我其实也不是说不要用这个，而是要找到合适的场景。
|
|
17
kahlkn 2021-04-30 10:31:38 +08:00
是的，我记得还有个场景也挺适合的 淘宝（网页版，或者阿里云网页版，当然仅仅是猜测） 在登陆后，过一段时间，来浏览网页的时候，右上角是登陆状态，并且有昵称的。 可以进行正常的 非敏感 操作的浏览，一旦涉及到 稍微敏感点的操作的时候，就会要求重新登陆。
目测（在线猜测）这个是类似于 双 token 模式，即 jwt token + session token 的模式。session token 的生命周期可能浏览器关掉就结束了，或者 无操作 2 小时之类的就结束了。 jwt token 的生命周期可能为 2 天之类的，其中内部保存着 比如 用户昵称之类的信息。 由此才产生了类似的效果。 |
 |
18
CallMeSoul 2021-04-30 11:01:31 +08:00
既然用了 token 验证的方式，那使用 jwt 作为 token 的使用广泛标准，怎么叫滥用？难道要自己自己实现个 token，想你说的生成个 uuid 才叫不滥用？
|
 |
19
mengdodo 2021-04-30 13:44:30 +08:00
如果你是多个子域名下的项目呢，你是不是要做 cookie 跨域；那如果又是不相关的域名呢，你是不是又要 JSONP 。折腾这么多，还不如 jwt 来的方便，各自项目使用相同 key 做下校验合法性就可以互通了，不香吗？
至于黑名单，踢下线这些骚操作确实是破坏了 jwt 设计之初的无状态性质，但是 总该是要理想迁就于现实嘛，慢慢演进就好了。 |
|
20
polyang OP @mengdodo 注意看我最后面那句话，不是非 cookie+session 不可的，也可以自己造轮子，随机生成一个 UUID 作为 token，会话保存在 redis 中。
|
 |
21
notejava 2021-04-30 16:44:18 +08:00
自己生成一个 UUID 也能用，但是大部分人都习惯用现成的，自己折腾怕有考虑不周的地方。
|
 |
22
slgz 2021-04-30 16:47:10 +08:00
公司撸码, 能跑起来不就行了(狗头)
|
 |
23
uselessVisitor 2021-05-06 15:02:00 +08:00
现在所谓的 JWT 都只是用 JWT 工具生成了一套 token 而已，实际上还是有状态的。。
|
Select Language