【 在 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.*