在 HTTPS 时代对请求进行签名是否还有必要？

今天看到百川大模型的接口文档 platform.baichuan-ai.com/docs/api 中要求对请求内容和时间戳进行签名，想到前几天在 V2EX 看到的帖子吐槽腾讯大模型 API 的签名( hesudu.com/t/975832 )。
而我们去看 OpenAI 等公司提供的 API ，是不需要这种签名的。
所以想讨论一下，在 HTTPS 时代这种签名是否还有必要？还是一种思维惯性？
我的理解：在 HTTPS 之前，这样的签名可以有效防止请求内容被篡改，是很有必要的，但现在 HTTPS 普及了，这里的好处并不存在了。另一点是重放攻击，我了解不多，请懂的朋友讲讲。

本贴不是讨论是否有了 HTTPS 之后不需要任何签名，而是讨论如百川、腾讯这两个例子里，对其他开发者提供 public API 时，是否还需要这种对请求体+时间戳进行签名的方式

好问题。我能想到的一点是，万一被侵入内网了呢

双向证书 https 的话，我觉得不需要

刻舟求剑

惯性思维，鉴定完毕。现在签名唯一的作用是反爬，自己提供的 API 还签名，纯属脱裤子放屁

签名对反爬没帮助吧？

＃5 当然有了，一个经过充分混淆的签名算法，至少能拦下一大批脚本小子

哦这个意思，不是 public API ，明白了

apikey 是与预共享的非对称可以避免抵赖

“与预共享”是什么意思

"但现在 HTTPS 普及了，这里的好处并不存在了。"需要 SSL pin 才能确保证书不是中间人的。现在 root 后的安卓手机，挂一个自签 CA 证书，实在太方便了。

这些 API 也不是给客户端环境调用的呀，是服务端调用的

确实没有必要，但国内主流都这么做，你不这么做就要解释为什么不这么做，教他们为什么 HTTPS 是足够安全的。天天解释累了，就加上了

个人印象中签名更多是防第三方客户端，把签名的 key 各种加密混淆藏起来，让你抓到包了也没法直接调用，得花时间找 key 。除此之外似乎就只有防重放攻击了。其实签名的 key 就是预共享密钥(PSK)了，配合 http 使用时完全可以把所有数据都加密。

认证用吧，没有 SSL pin 请求里直接放 secret 可能被中间人。

我也觉得没必要签名，不然我抓包都没意思了

"这些 API 也不是给客户端环境调用的呀，是服务端调用的"我一直是客户端调用的，当然我是自己用，不怕 api key 外泄。如果是服务器之间通讯，似乎确实没太大必要。就一个 MD5 ，就算有中间人，人家也随手给加上了。难是难在未知 KEY 的加密签名，比如 HMAC 签名，至少能防一部分恶意请求。

没必要，国内搞签名跟万年 java8 有异曲同工之妙，很多技术决策者的思想已经僵化了，举例子 OAuth1.0 标准是要求签名的，2.0 标准要求 HTTPS 后就去掉了签名非 public api 防爬虫防抓包啥的，其实是把签名当成加密来使用了，直接套一层 aes 效果更好也更简单

同感，跟别人解释过这个问题，对方没话说了就是一句万一 ssl 有漏洞呢。我心说能攻破 ssl 的人看得上你这点破数据吗？

微信支付的回调 api 是有独立证书的加密和验签的，这样可以保证你收到的支付成功回调是微信发出的而不是伪造的（因为你的回调接口在公网，如果这个地址泄露了别人就可以伪造支付成功请求给你了）。这种客户端调服务商的接口确实没什么必要，毕竟你的 access token 泄露了也不耽误服务商赚钱，只能说是防傻子的一道保险

并不是攻破，而是拒绝 https 又提供 http 服务，国内很多都是同时支持 http 和 https 的

现在讨论的不就是用 https 的前提下 api 签名还有没有必要吗？

证书就是签名，双向证书==双向签名，机制稍有差异而已----我问个问题。你是腾讯的服务器，现在有人请求修改 onwer A 的资源，你需不需要确认请求者就是 A ，如何保证？

GitHub Access Token AWS Access & Access Secret 等等，看场景。

日经日读，月经月诵

国内基本都是 app_id+secret很多三方 api 测试环境都是不带 https

你现在是 V2EX 论坛，现在有人请求 A 用户的数据，你需不需要确认请求者就是 A ，如何保证？

这两个东西完全不一样好吧。https 不防客户端自己抓包解数据，签名一定程度防这点。https 再厉害也是防止其他人截获数据，对客户端安装本地证书解密防御为 0 。Chatgpt 官网你 F12 看看能不能找到接口调用，就知道有没有签名了

身份凭证在客户手里，想通过在客户端搞一些加密来防客户作恶是不可能实现的。所谓的“一定程度”防只是防君子不防小人，app 可以反编译，web 里脚本明摆着。Chatgpt 怎么没有接口调用，返回内容是通过 Server-Sent Events 传的，身份认证用的是 JWT

我的理解是不需要的,都 https 了,为啥还需要额外加签验签?

＃11 不太懂。客户端服务端是相对而言的概念。我的服务端调用微信 api ，这里就成客户端了吧。

LZ 可以去看一下 ACME 里面关于请求签名的部分，可能会有一些全新的看法

那说得更准确些，是指 server 服务器，隔离可控的。客户端指安卓 iOS 网页等。

可以简单讲讲嘛

这里在说提供给开发者使用的 public API ，不是网站自己用的

不过 ChatGPT 官网的接口调用也没签名

如果我用 charles 抓包改请求/响应参数, 阁下如何应对

抓自己的包吗。。。（不确定你是否在开玩笑了

肯定还是需要的。用了 HTTPS 难道就不需要登录验证身份了么

额？对请求签名和“登录验证身份”有关系么？

我通过一个*SRF 漏洞修改你的账号发言权重

其实对请求签名防范的最核心问题是，你有些时候并不能保证请求内容和 token 来自同一可信源。举个底层逻辑相同但作用和机制完全不同的例子：CSRF token. 为什么明明用户都已经登录了，请求者拥有该用户的一切身份证明，为什么服务器还是不能完全信任这个请求？就因为服务器不能确定用户提供的身份证明能否证明他发起过请求内容。而通过下发 csrf token ，可以保证持有 session 凭证的所有者才能发起合法请求，这就能确认身份证明与请求内容是同一人发出的。签名同理。

这里讨论的签名一般就用的 2 种场景下：第一种：普通用户用浏览器等客户端调服务端接口要加签名，这种应该就是大家说的现在没必要的那种。因为大部分系统一般都是要登录的，调接口已经有了登录 token ，验证身份的问题就已经解决了。有的还要额外加签名，这种比较多的是金融类的公司，要求比较严格，为了防止中间人攻击什么的要加。然后有些普通公司可能是学到了也要加。这种在 HTTPS 下加不加呢，见仁见智，不做讨论。第二种：在自已服务器端调腾讯混元大模型接口这种要加签名，这种肯定是要加的。因为腾讯云就给你了一个 appid 和 appkey (可能给的不止这些，其他 secretId 、secretKey 同理)，然后有人要调腾讯云的接口，为了计费之类的，他得要知道你是谁，所以你要传 appid ，他才能算到你头上，但是 appid 又是公开的，要是你随便传了其他人的 appid 怎么办，所以就要你用不公开的 appkey 对参数进行签名，腾讯云收到后用只有你们俩知道的 appkey 对签名进行校验，如果一致，就说明你是真的 appid 所有人，这不就是验证身份么。至说你说的 OpenAI 公司没有签名，得要看是客户端 API ，还是服务端 API ，服务端 API 一定是要有签名的，可能它 SDK 已经封装好了，可以抓包看看有没有，如果没有那一定有问题。

就是抓自己的包. 如果后端没有完善的权限校验逻辑, 可以改参数绕过一些前端的限制.

＃41 签名可不同理，签名的算法多样，参数也多样，不是所有系统的签名都包含随机戳，拿签名当 CSRF token 用并不可行

请不要这样类比，不是一种东西。咱们就事论事。

你也说了是服务器端调用，然后又说 appid 又是公开的，这不是自相矛盾么。另一方面，为什么一定要有 appid+appsecret 呢？只有一个 api key 不行吗？OpenAI 的文档在这里，肯定是没有签名的： platform.openai.com/docs/api-reference/authentication

＃42 另外也可以看看 GitHub 的文档 docs.github.com/en/rest/overview/authenticating-to-the-rest-api?apiVersion=2022-11-28 也是只有一个 key 放在 header 就可以的

Remember that your API key is a secret! Do not share it with others or expose it in any client-side code (browsers, apps)

想表达什么呢？

要加的。主要是为了防止一些不懂装懂的专家和相关人员没事找事制造内卷和 KPI 。

这是你转的文档里面写的

如果请求者有 A 的签名，我就“认为是 A”至于到底是不是，那无所谓

需要，现在证书一般都是单向，还是可以中间人抓包，改请求的。加签能防止重放攻击类的

＃51 我知道，所以你粘贴这句话想表达什么呢？

抗抵赖。事中确权，作为识别真实性的依据（如果你说的是 HTTPS 是双向的话，可以考虑不需要）事后追责，作为日志完整性的记录。

如果使用单向 HTTPS 别说签名了，把请求/响应都用 AES 、SM 加密仍然可以破解、仿造请求，比如你看看 bj301 的请求。所以重要的是不要迷信单一的安全选项，尤其是 HTTPS签名+时间戳还是能滤掉很多重放攻击，参数更改的，不能说完全没有意义

appid+appsecret 和单 token 是两种鉴权方式，对于不会有回调场景的应用来说，单 token 确实足够了，但是对于有回调场景（比如微信支付，题中这个大模型我没用过不知道），回调的时候就可以让业务系统根据 appid 来判断属于哪个商户/公众号，这样可以减轻业务系统的开发难度，可以直接在提供的回调接口的路径上写上 appid 来根据 pathVariable 判断。回到你举例的文档和前面提到的 appid ，appid 的设计就是可以公开的，每个应用唯一的 id ，而单 token 模式下就没有这个可以区分的唯一标识了，使用哪种鉴权方式取决于产品的要求。

接上文，微信中的 appid 和 mchid 的设计使得公众号可以嵌入指定的小程序，可以绑定不在同一个主体下的商户，也可以使得一个商户可以绑定对个公众号。在这上面的绑定过程中，appid/mchid 就是绑定的标识，而不是根据主体名称/公众号名称之类的信息

＃57 额如果是回调区分业务的话，完全可以在业务层面实现啊。这跟签名毫无关系。按我的理解，appid+appsecret 是 oauth 的产物

私有接口很有必要、一定程度防止爬虫等公开接口一个鉴权 token 就行了、其他多余校验、纯属麻烦自己麻烦别人

哪有什么绝对的安全，如果是再用一些不常用的方式提供 API 接口调用，还不是项目经理在装 X ？

是的，和签名没关系，只是产品层面是否公开 appid 的区别。我猜这个大模型用签名是公司上游中间件只支持了签名的模式，没有支持单 token 的授权模式，在他这个场景签名确实没有必要

现在签名主要也就是防重放和随意修改链接参数了。

就事论事, 签名只能防止数据被修改, 不能防止中间人看数据. 和 HTTPS 解决的部分问题是一样, 但 HTTPS 做了更多.那么强调签名必要性的愿意就只有一个了, 不信任 HTTPS.不信任 HTTPS 机制, 那就真是大牛.如果信任 HTTPS 机制但还是不信任 HTTPS, 那就是不信任 CA.CA 被攻破的概率不是没有, 但我觉得绝大多数人应该是信任 CA 的.

国内营商环境环境，你接口不做校验防御，能刷死你https 只能防止第三方中间人，不能防止别有用心的用户。跳过 SSL PIN 的方法，太通用了，随便搜下就有方法内置白盒加密算法 + 代码混淆能挡住 90%的人，起码破解没那么容易。如果是对公的 api ，我记得阿里一些接口是直接给白盒 sdk ，accesskey 是不在代码里面的

测重点不一样， HTTPS 保证的事传输安全接口签名保证的是客户端身份和请求有效性

Public API 还非要加，有时候也不是后端的要求可能公司的对外统一网关就是这个要求

综合来说目前各大平台的签名主要保证了防重放防修改和不暴露 key 的情况下进行鉴权，跟 https 还是不重叠的，所以加了安全性还是会提高一些(当然我还是喜欢 key 放 header 一把梭的接口。。) 也可以防中间人的，有些服务用的非对称通信，反正越搞越麻烦了

服务器对服务器单向调用的情况下，我觉得签名确实没必要，一个 token （或者叫 apiKey secret 之类的）可以识别当前请求者是谁就行了，这种情况下，加上 https 单向认证，以及 TLS 中本身包含的序号和时间戳可以防止请求重放，从网络层面，以我的见识想不到什么攻击的地方。上面几个楼层说的签名也确实有其应用场景，但不是楼主想问的场景。

＃69 纠正一下：以及 TLS 中本身包含的序号可以防止同一 TCP 连接中对某一次请求的重放

一个是传输层安全一个是应用层安全根本不同的应用场景大部分服务器架构都是用负载均衡承接 SSL ，进了内网就都是明文了。所以有些应用层会单独加一个安全校验。因为他不能保证外部请求被通过 SSL 来调用。

1.有些项目部署的时候可能会让 https 的服务器证书前置化，在防火墙层就已经解密了数据了，然后后端都是 http 的，这时候业务部门不希望关键的数据被网络运维部门的人知道，避免不必要的隐患。2.重放攻击3.相关法规硬性要求。总之HTTPS 保障传输中不被中间人窃取签名是保证增加一些篡改和窃取的难度

抓包改请求，防重放用的，和 https 我只能说有交集但是不多。

楼主这是没被爬虫毒打过。

我这边有个场景，不知道是不是跟楼主说的是类似的玩意。后端需要给前端返回一个带 sign 的 wss 地址，前端连接该地址实现 sdp 的实时交换。

其实就是相当一部分人不能理解浏览器控制台能看到所有明文数据是正常的，然后疑问这也能算加密？殊不知整个浏览器包括他所看到的内容都是客户端的一部分，能看到明文是理所当然的。再深入就是内存安全和操作系统安全了，但说这些他们又不懂了，还是所看即所得的思维。

但是实际情况并不是 hsts 情况，

up 说的是那种对请求内容进行计算得到一个哈希串的方式吧，其实必要性真的几乎没有，不过目前国内互联网好像流传着 https 也并不安全的思想，虽然我也不知道这个思想是怎么流传起来的

本地给你来个企业根证书就能绕过 https 了。

对的