没有 https 的情况下， jwt 是不是也不安全？

http 就是不安全的

可以这样理解 通信安全和身份校验是两回事

有 https 不是也可以吗

服务端好像从来都不知道请求是不是真正的用户吧，只能说发个凭证给用户，用户每次请求带有这个凭证就认定是这个用户。
这个和 HTTPS / HTTP 没啥关系，HTTPS 的安全，没双向认证的话，只能让用户安全些，服务端该不安全还是不安全。

jwt ，oauth 都是认证方案啊。因为 http 只能传输文本，没有别的更多的信息。不过，你要是说在 jwt 里还打包了你请求的源 ip ，然后通过对比后续请求过来的 ip 是不是和 jwt 中的一致，还是能勉强做一下安全的。但这种别人只要切换网络导致 ip 变动就会自动掉线了

换个说法，抓包拿到用户名密码之后模拟请求，是不是服务端根本分不出请求方是不是真正的用户。

鉴权和加密和防篡改，是几码事

@IvanLi127 走 https 的话，数据加密，可以避免中间抓包吧

jwt 安不安全跟 http 没关系吧

安全是多方面，多环节的。任何一个环节有漏洞就是不安全的。认证只是其中一小步。

jwt 是否安全 和 https 没有关系。

jwt 本身是自洽的。 但是不能明文传输，所以 jwt+https 结合使用就比较安全，比如网站的登录态

jwt 用的是是鉴权和防篡改，而不是考虑加密。jwt 也不存敏感信息
计算机安全是包含认证和授权，而不是仅仅加密。

看你如何定义安全啊

https 只是保证两个点之间中间链路传输的安全，所以通过一些操作也是可以用中间人方式绕过的

@NoKey 得看客户端有没有信任中间人证书咯，不过这个也保不了服务端的安全呀，没双向认证的话只能保客户端不会访问错服务端。

鉴权机制只是安全机制的一部分，不是全部
有人拿着你的银行卡和密码就能取出钱来，银行不会考虑这人是你的亲戚还是绑匪
但是他可以通过行为机制冻结银行卡，如果你的转账目标是可以账户，如果你的金额过大等等，他会冻你的卡
如果你想保证账户安全，你还需要行为检测，账户风控系统，不能只靠鉴权

jwt 有点像景点门票🎫，验票人员只能检验票的真假，但票是不是你的管不了

加密和认证不是一个东西

jwt 包含的信息怎么解开？

JWT 只能保证 token 不能被伪造，没有其他安全功能。
HTTPS 只能保证数据出了终端后不被第三方知道内容，前提是终端是安全的。

在谈安全的时候，往往是谈针对哪种问题是安全的，没有任何一种手段能解决所有安全问题。

是的。

像 Oath ，jwt 这些认证手段，他们的主要作用是在 Web 应用中保持你的登录状态，不至于让你每次操作都要输入用户名和密码。

而 HTTPS ，它属于信道加密，防止你跟 web 应用的通信内容被监听、篡改，学名叫中间人攻击。像你用的抓包就是一种中间人攻击。HTTP 因为用的是明文传输，无法避免这个行为。而 HTTPS 结合了非对称加密+对称加密+CA 作保，确保你访问受信任的网站时，通信内容别人看不懂。

https 主要是防止中间人劫持流量

并不绝对。比如，你可以在 http 协议下，通过 body 依照 tls 协议实现一遍。

jwt 只是一个 token, 里面不存敏感信息. 不存在安不安全这一说法. 只要你的密钥不泄露. 就安全..

https 保证通讯安全。jwt 只是保证认证的格式，你用自己生成的随机数都可以，只不过它带有一些基础信息，可以省去向中心服务验证的过程。

客户端拿到 token 后，要自己存在一个安全的地方。
- 像浏览器场景，基本都要存在 http-only 的 cookie 里。这个 http-only 表示只有浏览器能读取，js 无法读取。跟 http/https 没关系。这样能保证攻击注入的 js 无法读出你的 token 。
- app 场景，应该是直接存 app 本地就好，别的 app 读取不到，没写过 app 不知道这方面的安全规范。
- server 2 server 场景，你拿到 token 后就自己存好，方式各种各样。大部分情况下，因为这个 server 只有你能访问，所以直接明文“随意”存个位置也是可以的。

你辛辛苦苦把 token 保存得很好，但是对外传输的时候竟然用了明文的 http ，那别人就特别容易截到你的 token ，来伪造你的请求。比如，把你网上银行的钱转走。。。

https + jwt + cookie （ httpOnly + secure + Samesite=Strict ）+ ip + deviceId + reCAPTCHA

这都不是一回事...

最近好多帖子关于签名、jwt 、https 的，分不清“所谓安全”：
“第一种安全”：你不想你的接口被第三方工具请求，请求只能从你的客户端 APP 发出。
“第二种安全”：你的数据在传输过程中，不想被电信运营商等中间人偷看。
“第三种安全”：验证用户是是否已认证或已授权，防止越权访问。

你把安全理解成舒适,你把你开发的引用比喻成造车,
HTTP 相当于泥泞坑洼的小路
HTTPS 相当于平坦的路
你的程序和别人的程序就是车
安全与否就是舒适与否
别人的豪车开在 HTTP 上 也会觉得不舒服,这是外部的
你的平板车开在 HTTPS 上 觉得不舒服,这是内部导致的

@gps949 你不能安全实现，攻击者预计可以直接修改你的代码，剥离或者直接魔改加密代码，而且 TLS 的核心在于证书链，要有方法证明证书符合需求，因为你的代码和证书终究也还是通过 http 传输的
（当然你可以说你能给代码加 114514 层混淆，但这么比就没意思了）

@codehz
还没回复你，你为啥要说 114514 层混淆这种先自己杠自己的话呢……
个人从 0 手搓协议，完善性肯定有问题的。你不说我也认可，我相信每个人都认可。

但我只是说的一种可能性不是么？我一上来说的也是“并不绝对”，而不是“绝对安全”吧？
就比如 OpenSSL 也是肉体凡胎的人们写的，也出现过 Heartbleed 这样极为严重的 Bug 。也就是你即使不自己手搓，使用全球广泛使用被认可的现有协议实现，也依然不能绝对规避风险。

另外你提到证书链、代码这些，我是这个行业内的，所以这些很清楚。
即使你走 HTTPS 协议，浏览器也是通过 CSP 、KeyStore 、P11 这类接口调预先配置的证书链（受信根证书颁发机构），很多中间人攻击 HTTPS 协议，也是通过在客户端安装它的 CA 根证书实现的。
这些跟代码混淆不混淆这种前端技术没啥关系，因为 RSA 、SHA 这些 SSL/TLS 协议用到的密码算法套件实现可以完全公开，完全没必要混淆。至于公钥（证书）本身就是公开的，也没必要混淆。
SSL/TLS 协议本身保障能力也就是针对信道，无法保护终端。比如客户端篡改系统受信根证书颁发机构、客户端篡改代码让客户端不执行对服务端验证、客户端窃取已经解开的明文数据、（双向 SSL 情况下）客户端“骗签”这些，都不属于 SSL/TLS 保护范畴。仅仅靠标准浏览器+标准 HTTPS 协议本身（不添加其他 SSL/TLS 协议外的实现）也无法防范。

@gps949 问题就是中间人攻击在 http 的场景下，不需要在客户端上搞事情啊，只要中途魔改你的代码即可，你没有任何办法验证，因为验证的代码也可以被改，不是说你实现有问题导致出事，而是就算实现完全没问题，假设一点协议上的漏洞都没有，它也不能提供任何可靠的安全保障
https 的一个性质就是双方有一个预先共享的信息（和代码），而这个信息和代码显然不能通过同一个不安全的信道传输
一个最简单的攻击方案，中间人直接在它设备上模拟浏览器，将渲染结果传递给受害者，然后把受害者的输入通过这个模拟浏览器传回服务器，而这个过程中，受害者除了真的去阅读每一行代码以外（实际上不可能），没有任何感知
https 的情况，你中间人要做这个，在没有服务器的证书的情况下，就没办法伪造你服务器的身份，因为验证代码和证书链都是已经预制在客户端上的，你不能在不接触客户端的前提下去修改验证代码或者注入证书，因而客户端总是会显示证书错误信息

这个问题也可以这么问：
没有 https 的情况下，Cookie 、SESSIONID 是不是也不安全？

jwt 就是明文，只是保证没有被篡改，抓包的 jwt 可以随意用