API接口已经有HTTPS的前提下，为什么还需要签名机制？

Question

注意场景：

1. 服务端对服务端的接口，不是客户端对服务端的接口
2. 防止中间人可以PINNED Pub Key，因此中间人攻击不在考虑范围内
3. 极端条件可以使用客户端证书

综合以上三点。为什么在Https的保护下，还要额外做签名验证？

主要疑问，如stripe的退款接口curl https://api.stripe.com/v1/refunds -u "$密钥:" -d charge=$charge_id就可以发起一笔订单的退款或者扣款。没有签名的Stripe岂不是非常危险？

Answer 1

总结自答：

https+签名会『更』安全。

但是，https自身的安全程度足够，没有再额外增加签名机制的“必”要性。

安全问题主要出在客户端自身网络环境安全。

补充：
签名特指的是：根据请求参数做一定的排列然后使用hash算法或者rsa等非对称算法计算出来的一个额外参数。

Answer 2

https仅是网络传输上对内容加密保护。
签名验证，我觉得主要是为了识别请求的身份和权限管理，如果不做区分的话，那就是服务器对所有人都可以响应相同的信息，没有权限和身份的区别，那你就可以不需要签名验证。

以上是个人理解，供参考。

Answer 3

https://www.zhihu.com/questio...

Answer 4

https通常是单向验证，即用户可以验证服务器是真的服务器
token是用来验证你是你，而不是其他人

Answer 5

我今天看到你这个也纠结了，我有2点当然可能不是针对微信支付的场景
1、就是f12后看到了请求体，然后自己伪造数据请求接口，比如注册，我看到了body里是三个字段账号、昵称、密码，然后我伪造了一堆假数据（你可能觉得这样没意义，但是我们线上确实遇到这样无聊的人）这时候加个签名是不是比较好

2、就是你说的防重放问题，既然第一点3个参数可以自己乱传，那么timestamp也可以乱传

Answer 6

确实，有了 SSL 签名显的多次一举，比如微信的网页授权获取 access_token，也是没有签名的（直接把秘钥当做一个参数传输）：

https://api.weixin.qq.com/sns...

可能他们担心：万一哪天 SSL 的安全层被攻破了，秘钥直接传输，就被攻击者观察到了。

Answer 7

https保证了内容传输过程的安全和加密
但是恶意调用者你怎么防范?比如你是公网api,任何人调用你都响应不太行吧?
或者你是内网api,其他不相关的应用调用你也不太合适吧,也要考虑内网的某些对外开放端口和服务的服务器中毒的情况