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

[NoKey]

抓包拿到 jwt 之后模拟请求，是不是服务端根本分不出请求方是不是真正的用户。
所以说，所有的安全，都应该是由 https 来兜底？
其他各种 jwt ，oauth 什么的，都是一种认证方法，不是安全机制？

[cnuser002]

是的。

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

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

[wanguorui123]

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

[gps949]

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

[BBCCBB]

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

[justdoit123]

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 ，来伪造你的请求。比如，把你网上银行的钱转走。。。

[fescover]

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

[Ericcccccccc]

这都不是一回事...

[iX8NEGGn]

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

[duwenink248]

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

[codehz]

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

[gps949]

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

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

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

[codehz]

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

[amxsa]

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

[wtfedc]

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