- 主题:jwt相比普通token，优势在哪？
破不了。所以一般 jwt 自带有效期比较短
【 在 feed (鳄鱼) 的大作中提到: 】
: 针对于服务器可以自己验证签名，我倒有一点不解：
: jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
--
FROM 111.193.254.*
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 标 题: Re: jwt相比普通token，优势在哪？
: 发信站: 水木社区 (Thu Mar 14 17:05:34 2019), 站内
:
: 所以说 jwt 更不安全。。
没有哪种方案是绝对安全的，都需要 trade off
:
: 基于 sessionid 的认证可以搞 csrf，而 jwt 不行。
csrf 只会发生在 web 场景，为什么呢，因为 web 使用 cookie。走 cookie 通道的都有 csrf 问题，不论是 sessionid, jwt, login/password, apikey/apisecret, bblabbla.
sessionid 的认证和 jwt 的认证不在于是否走 cookie "通道"，而在于是否自签名。
如果不自签名，则需要服务端引用大规模分布式存储来排查，如果自签名，则不需要分布式存储
:
: jwt 本身是加密的，理论上当然不能被解密。但是黑客的攻击当然不是简单地破解里面的信息。比如可以入侵 admin 的计算机，取得这个 jwt 以后在别的地方入侵远程的系统。使用 jwt 的服务器没法简单地吊销 admin 的 jwt，除非它维护一个越来越大的黑名单。
jwt 当然也可以吊销，办法是引入一个专门用于保存吊销数据的分布式存储。
虽然架构 fallback 到旧方案，但是规模可能小很多
:
: 它许诺的广告疗效还包括更容易横向扩展之类的。但我没看明白这个更容易是怎么个容易法，比用一行命令架构 redis 服务器还容易？
session 数据是不建议存放在 redis 里的，至于 redis 为什么不适合干这个事情，有些跑题了，可以多了解服务端开发的架构
:
: 【 在 feed (鳄鱼) 的大作中提到: 】
: : 针对于服务器可以自己验证签名，我倒有一点不解：
: : jwt是把明文和对应的签名一起封装到一个jwt中去的，那么黑客如果截获了这个jwt，然后伪装客户对服务器发信息，怎么破？
:
:
: --
: 灭绝人性啊
:
:
: ※ 来源:·水木社区 newsmth.net·[FROM: 111.142.201.*]
--
FROM 111.193.254.*
jwt 这种也算新技术啊。。本青多年前就往 response 里面写 json 加密头了。每种技术都有优势和劣势，仔细分析才能应用到开发里面。你不要抓个新玩具都像拿到金羊毛一样高兴好不好。
要不我再放个大招吧。要说句不客气的话，放在整个软件开发领域，某个社区一票层出不穷的东东都不配叫”新技术“。
【 在 eGust (十年) 的大作中提到: 】
: 最后我还想多说一点，跟技术本身无关。如果你带着偏见去看一门技术，就会连 csrf 怎么在 jwt 里面实现这种问题都能问的出来。不是针对某个人，老鱼别想太多。这是一个普遍现象，不光天朝，不光码农，全世界的人都一样。
: 随着年龄的增长，除了注意身体健康以外，我也是时刻提醒不要用抵触的心态去看新东西。这可能跟本科时的教育有关，当时老师的大意是，政客认为正确的东西，都是他大学时代的知识。引申出去，人到了一定年纪就不容易接受新知识了，这跟人们普遍的印象，年纪越大的人越不容
: 前两天看到一个吐槽，我觉得道理是一样的，道格拉斯·亚当斯的科技三定律：
: ...................
--
FROM 111.142.201.*
不是说 session 能避免 csrf，我是说在 sessionid 技术下很容易解决。而在 jwt，还得引入 fallback 方案。额外的开发是小事，但我估计很多程序员估计会直接省掉吧。
要我看，jwt 需要在非常大规模的 web 开发，以至于 session 存储的开销成为重大问题的情况下才能应用。以及应用在非 session 相关时。现在被误用得太厉害了。
session 不要存储在 redis 里面这一条倒是很有意思。可以说说。
【 在 menghan (skybluee) 的大作中提到: 】
: 没有哪种方案是绝对安全的，都需要 trade off
: csrf 只会发生在 web 场景，为什么呢，因为 web 使用 cookie。走 cookie 通道的都有 csrf 问题，不论是 sessionid, jwt, login/password, apikey/apisecret, bblabbla.
: sessionid 的认证和 jwt 的认证不在于是否走 cookie "通道"，而在于是否自签名。
: ...................
--
修改:hgoldfish FROM 111.142.201.*
FROM 111.142.201.*
browser 自动管理 cookie 客户端不用管，设个 http only 又不用担心第三方 js 读，好处自然也是有的。所以这东西没什么绝对好或不好，最后选什么技术怎么用，都是各种利弊权衡之后的结果
【 在 menghan (skybluee) 的大作中提到: 】
: 没有哪种方案是绝对安全的，都需要 trade off
: csrf 只会发生在 web 场景，为什么呢，因为 web 使用 cookie。走 cookie 通道的都有 csrf 问题，不论是 sessionid, jwt, login/password, apikey/apisecret, bblabbla.
: sessionid 的认证和 jwt 的认证不在于是否走 cookie "通道"，而在于是否自签名。
: ...................
--
FROM 101.98.83.*
我明白你想知道 jwt 到底比 session(id) 方案好在哪儿，其实我已经说了，可以通过算签名比对的方式不依赖大规模分布式存储。
但是你觉得这有什么了不起，对不对，session 的方案已经很全很完善了，依赖一个存储有啥问题，更何况说不定可以使用 redis，redis 又快又方便，为什么要开发另一类东西。
我想说，你对大规模，对什么叫分布式存储，一无所知啊
我觉得再说就得重开一个题目，作为对一个合格开发者的尊重，我也不适合在这儿讲课，又不是老师，可以自己去查查，开发和维护分布式存储有什么难的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 不是说 session 能避免 csrf，我是说在 sessionid 技术下很容易解决。而在 jwt，还得引入 fallback 方案。额外的开发是小事，但我估计很多程序员估计会直接省掉吧。
: 要我看，jwt 需要在非常大规模的 web 开发，以至于 session 存储的开销成为重大问题的情况下才能应用。现在被误用得太厉害了。
: session 不要存储在 redis 里面这一条倒是很有意思。可以说说。
: ...................
--
FROM 111.193.254.*
插一句：jwt是可以在分布式架构下回收的，这里有公开的商用方案。
https://fusionauth.io/blog/2019/01/31/revoking-jwts
消息中间件在大部分互联网公司都是业务常用场景，所以用在jwt上也不会太重。
--
FROM 101.93.207.*
给你找台阶下……都不新鲜了还问 csrf 怎么生成这种不用动脑子的问题
【 在 hgoldfish (老鱼) 的大作中提到: 】
: jwt 这种也算新技术啊。。本青多年前就往 response 里面写 json 加密头了。每种技术都有优势和劣势，仔细分析才能应用到开发里面。你不要抓个新玩具都像拿到金羊毛一样高兴好不好。
: 要不我再放个大招吧。要说句不客气的话，放在整个软件开发领域，某个社区一票层出不穷的东东都不配叫”新技术“。
--
FROM 101.98.83.*
但为什么用 session 就一定会依赖”大规模“分布式存储呢。jwt 不用大规模分布式存储的”优势“依赖于 session 管理必须用”大规模“分布式存储这个劣势。再者，多大算大规模呢？分布式存储可是动不动玩 PB 级别的数据。。TB 级我看是没多大规模。
再来就是大规模分布式存储很麻烦这件事。问题就来了，真的很麻烦吗？又不是 ceph/swift 这种对象存储、块存储。就算是使用分级存储的情况下，我觉得也真心很简单了。
不能用 redis 存储这件事是比较反后端程序员直观的，也刚好跟本线索的”大规模分布式存储“有关。有兴趣可以聊一下。
【 在 menghan (skybluee) 的大作中提到: 】
: 我明白你想知道 jwt 到底比 session(id) 方案好在哪儿，其实我已经说了，可以通过算签名比对的方式不依赖大规模分布式存储。
: 但是你觉得这有什么了不起，对不对，session 的方案已经很全很完善了，依赖一个存储有啥问题，更何况说不定可以使用 redis，redis 又快又方便，为什么要开发另一类东西。
: 我想说，你对大规模，对什么叫分布式存储，一无所知啊
: ...................
--
FROM 111.142.201.*
你还是仔细看一下前面的帖子吧。上面几个人在说 jwt 要做 csrf 得依赖 fallback 方案了。
顺便说一下想拿 jwt 来代替 session 还有一个问题。jwt 如果要主动失效旧的 token，那用户就不得不总得重新登录。这通常是反用户体验的——别跟我说什么不安全，这就是业务需求。而 session 方案，存个天长地久都没问题。
【 在 eGust (十年) 的大作中提到: 】
: 给你找台阶下……都不新鲜了还问 csrf 怎么生成这种不用动脑子的问题
--
FROM 111.142.201.*