- 主题:jwt相比普通token，优势在哪？
当然破不了啊，你觉得有啥技术能破说来听听？
【 在 feed (鳄鱼) 的大作中提到: 】
: 针对于服务器可以自己验证签名，我倒有一点不解：
: jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
--
FROM 122.60.88.*
你在搞笑么……都拿到别人 session id 了，为啥不能直接发 request？
如果你说放 cookie 然后设 http only，那 jwt 也一样能放啊
拜托发帖的时候过一过大脑好么，真的是越来越觉得你小白了……
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 所以说 jwt 更不安全。。
: 基于 sessionid 的认证可以搞 csrf，而 jwt 不行。
: jwt 本身是加密的，理论上当然不能被解密。但是黑客的攻击当然不是简单地破解里面的信息。比如可以入侵 admin 的计算机，取得这个 jwt 以后在别的地方入侵远程的系统。使用 jwt 的服务器没法简单地吊销 admin 的 jwt，除非它维护一个越来越大的黑名单。
: ...................
--
FROM 122.60.88.*
鉴于你在各个版问的水平，那么忠告你一下，如果你的 cookie 被别人拿到了，那么服务器是没办法区分是不是你本人的。有的服务器可能会做登录 ip 的验证，跟你一个局域网就没差别了。不管是 session id 还是 jwt，对于客户端都是完全没差别的。
【 在 feed (鳄鱼) 的大作中提到: 】
: 原来和我一样不理解的人大有人在呀
: 我以为就我不懂得里面的玄机奥妙呢
--
FROM 122.60.88.*
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 标 题: Re: jwt相比普通token，优势在哪？
: 发信站: 水木社区 (Thu Mar 14 17:05:34 2019), 站内
:
: 所以说 jwt 更不安全。。
:
: 基于 sessionid 的认证可以搞 csrf，而 jwt 不行。
:
: jwt 本身是加密的，理论上当然不能被解密。但是黑客的攻击当然不是简单地破解里面的信息。比如可以入侵 admin 的计算机，取得这个 jwt 以后在别的地方入侵远程的系统。使用 jwt 的服务器没法简单地吊销 admin 的 jwt，除非它维护一个越来越大的黑名单。
你要是一个 jwt 里面不签失效时间那怪谁？admin 那么容易被攻击还一次签一年怪谁？
你用 redis 可以重启服务让所有 session 失效，我用 jwt 可以直接换一对密钥，有啥不能简单吊销的？
:
: 它许诺的广告疗效还包括更容易横向扩展之类的。但我没看明白这个更容易是怎么个容易法，比用一行命令架构 redis 服务器还容易？
jwt 不需要额外的系统。多一个系统部署上的复杂度就大幅增加，scale 的时候就更困难。这么简单的道理还需要解释？
:
: 【 在 feed (鳄鱼) 的大作中提到: 】
: : 针对于服务器可以自己验证签名，我倒有一点不解：
: : jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
:
:
: --
: 灭绝人性啊
:
:
: ※ 来源:·水木社区 newsmth.net·[FROM: 111.142.201.*]
--
修改:eGust FROM 122.60.88.*
FROM 122.60.88.*
不正常我把 admin 账户禁掉不行？为啥非得挑？
jwt 一般也都是多组 key，直接废掉一组 key 行不？
你还是了解一下 csrf 怎么回事儿吧，我们 rails 打从第一个版本就带这东西了
难不成你觉得发个 request 填一个从 get 明文能拿到的 header 异常困难？人家 session id 都拿到了就不会重新 get 一个？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 因为 sessionid 可以被吊销啊。比如检测到不正常的业务跳转就 invalidate admin sessionid. 或者运营人员禁用不正常用户写个脚本从 redis 里面清除它们的 sessionid. 你来说说用 jwt 这个需求怎么玩？
: 还有 csrf 是不是可以了解下。拿了 sessionid 也不一定能发 request 哦。
--
修改:eGust FROM 122.60.88.*
FROM 122.60.88.*
因为 session management 不光一个 redis 那么简单啊
人家 jwt 不需要多点击两下啊，为啥要多点两下？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: redis/memcache 服务早就是非玩具 web 系统的标配了。哪来的多一个系统。
: 至于 redis 的 scale，用公有云是一个点击，用自建服务器，可能是两个点击吧。
--
FROM 122.60.88.*
我服了，为啥用 jwt 就不能做 csrf 了？
csrf 防的只是给你嵌一个 get 链接这种弱智攻击，人家说的情景都拿到 session id 了，你一个 csrf 有啥用？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 禁掉 sessionid 要求重新登录不是更好。你直接把 admin 禁用掉这算什么呢？
: 看你的意思，你是打算否认 csrf 攻击的存在吗？这是另外的话题了。有空再聊。
: 如果你不否认 crsf，那你仔细想一下，不维护 session 怎么在服务器保存 csrf token 用于验证客户端传过来的 token? jwt 能否实现这个目标。
: ...................
--
FROM 122.60.88.*
……
这东西好不好用跟你已有系统或者现有系统用不用有啥关系？
你要是开发个百八十人用的东西，或者本来跑得好好的服务，还非得拿掉 session 重新用 jwt 那是自己作。这跟技术本身有啥关系？
讨论一件事的时候能不能不要和稀泥把乱七八糟没关系的都扯进来？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: session 管理早就是各种 web 框架必备的，就是这么简单。
: 背后还有一系列的中间件依赖 session 处理各种认证、缓存。你用 jwt 就先把这些都废了重新写。
--
FROM 122.60.88.*
一样啊，csrf 就是一个 random token 而已，我后端再生成一个 jwt 把 random token 和用于身份验证的 jwt 都签在一起不就完了？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 拿到 sessionid 发动重放攻击跟 csrf 攻击是两件事。我原本就是分成两段话来讨论的。你为啥非常要混在一起呢？
: 至于 jwt 能不能做 csrf，要不你来说说后端不搞 session 的方案吧。
--
FROM 122.60.88.*
啥意思，没看懂，但跟旧的 session id 要不要通过验证是等价的，session 啥样 jwt 就啥样
你要搞清楚，jwt 跟 session 在本质上是没差别的，都是证明是由服务器签发的 token。不同的是验证方式，session 放在内存/硬盘里，jwt 不存，通过私钥来验证签名是由服务器发出的。session 需要把跟 token 对应的信息都放在内存/硬盘里，jwt 把对应的信息放在签名里面了。
其它的方面没有任何差别，任何你觉得需要放在服务器内存/硬盘里的东西，通过私钥签个名连带着关联的东西发出去就完了。甚至是不是 jwt 都不重要，只不过 jwt 标准化了，各个语言都有实现。
用 rails/django 这种最早一批的，肯定是默认自带 session 的。但是如今重前端的话，好多后端都是 micro service，裸 http 服务啥都不带，需要什么自己装 middleware。你可以选择 session manager，然后配置一下 redis 服务器之类，或者不折腾的话默认大概率存硬盘。同样你也可以选择装个 jwt 的中间件，然后生成几组 key，琢磨一下签出去的东西里面需要包含啥信息。这种情况下你觉得选 session 有任何优势么？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 旧的 jwt 要不要通过验证？
--
FROM 122.60.88.*