@Newyorkcity 尽量减少不必要的暴露。客户端不能完全信任，浏览器也有正经的和不正经的，正经浏览器也可能装了恶意插件。当然，真出问题的可能性不大，但你要做的事情足够敏感时就不得不防

服务器之间的通信，不会经过浏览器，https 保证了没有中间人(除非 Google 脑抽泄露了私钥或者把私钥共享给了不靠谱的第三方 cdn 之类)

code 是经过客户端转发给 Foobar ，而不是 Google 直接发给 Foobar 的，Foobar 无法直接验证真伪，得自己去找 Google 问一下(通过 https ，可以验明 Google 正身)。

但如果用 SAML 这样的协议，可以不用回 Google 二次验证，因为认证结果(Assertion)是带签名的，签名用的公钥在前期配置过程中就已经同步给 Foobar 了

办了中信联名的，实体卡黑色网纹挺好看的。现在返现比较少了，一笔也就几分钱。满 19 可以去中信那个 app 里抽额外的返现红包，这样每笔还能多返两三毛，刷小额还算实惠。但这卡没有中信积分，刷多少都是 0 积分。银联自己的权益都有，机场停车什么的，无界卡现在有境外消费(包括线上)立返 1%，但你得找到能刷银联的地方

@ZeroClover 各种什么私钥泄露问题只要一个 HSM 就可以解决问题，私钥只进不出，所有调用只在 HSM 能完成签名，然后将签名结果给服务器。除非你买的是带后门的 HSM，或者刚好撞上有设计缺陷的 HSM 。

是的，HSM 确实是为了防止私钥泄露而设计的，这是很重要的安全设备。但也不是厂商声称使用 HSM 就万事大吉了。就楼主说的 https 请求里直接传密钥这种情况：
正常 CDN 厂商： https 密文 -> HSM -> http 明文 -> 应用各种 CDN 规则 -> HSM -> https 密文 -> 真正的 https 服务器
二逼 CDN 厂商： https 密文 -> HSM -> http 明文 -> 应用各种 CDN 规则，同时记一条日志 -> HSM -> https 密文 -> 真正的 https 服务器
恶意 CDN 厂商： https 密文 -> HSM -> http 明文 -> 应用各种 CDN 规则，全流量备份下来以后留着用 -> HSM -> https 密文 -> 真正的 https 服务器

先不说厂商是否真有恶意，就是记个日志都有可能不小心把请求里的密钥存下来，然后这个日志谁能看到咱就更不知道了。

@dzdh Paypal 、Stripe 没有客户端证书。因何安全？

PayPal 等不使用客户端证书(或者准确的说，mutual TLS)，也不使用签名(这里明确以下，我说的签名都是指请求端使用非对称密钥里面的私钥做的签名，服务端可以使用对应的公钥验证，只是把请求参数 hash 一下那个不叫数字签名)，直接在 https 请求中传递原始密钥，可能有几种原因：
1. 设计 API 的人心比较大
2. 当初设计的时候没想清楚，已经有不少客户在用了，也很难改了
3. 为了降低使用门槛，做出了牺牲

Google 的 Cloud API 提供了多种验证机制，其中的 API key 就是直接通过请求参数传递，但是现在内部已经在绝大多数场景禁止使用了，替代方案是使用服务帐号的私钥进行类似 mutual TLS 的认证。对于外部用户，仍然允许使用 API key (也只是建议在访问公共数据的时候使用)，主要也是出于上述 2 和 3 的考虑。

还是那句话，安全是相对的，
绝对安全 > https with mutual TLS >= https without mutual TLS + 请求端私钥签名 > https + 明文密钥 > 绝对不安全
看你自己的应用场景选择合适的。

@dzdh 纯『技术上』说，『仅仅 HTTPS 不使用签名』其实并无问题？

这样的说法有一定误导性，当今 https 最广泛的应用场景都是不使用客户端证书的，还是需要强调一下

@dzdh 链路问题可以设置成全链路 tls 吧？如 cloudflare ？阿里云、腾讯云等众多 CDN 厂商的 cdn 也是支持 https 回源的

其实这里还有一个问题是你要把 https 私钥分享给 CDN 厂商，这些大厂就这么可信吗？反正我胆子很小。。

@dzdh 看了一下你的其它回复，在＊有客户端证书＊的情况下确实没必要对请求额外签名，这两个原理上是等效的，或者说签名只是客户端证书的屌丝版。

@dzdh - https 服务端的密钥是怎么管理的，都有谁经手了，不小心泄露了呢？
回：签名模式的密钥怎么管理的？都谁经手了，不小心泄露了呢？

不是这个意思。我作为参与通信的其中一方，无法保证对方的安全管理足够好，我最多只能控制自己这一边。对于使用了 https+签名的情况，从服务端的角度看，某个客户的签名密钥泄露只会影响这个特定的客户；从客户端的角度看，服务端的 https 密钥泄露等同于通信变明文，但别人还是伪造不了我的签名。两种情况都比最好情况好很多。

- 签发 https 证书的 CA 是不是足够可信任呢？
回：本地指定 CA 文件验证

这个指的是 CA 本身被攻击，导致客户密钥泄露，甚至主动参与犯罪 /配合有关部门。当然这种可能性很小，但小不等于没有。

以上讨论的出发点都是 “https 防中间人是有条件的”，与题主的问题没有直接关系。

再多嘴一句，其实 https 网站很多很多时候都不是全链路加密，tls termination 发生在负载均衡，甚至更前面的某个第三方(比如 CDN 或云厂商)的反向代理或者所谓应用防火墙上上，后面都是明文，就算是在内网，走明文也是非常不安全的。

安全从来都是相对的，一般我们是可以认为 https 是可以防中间人的，但这也是有前提的：
- https 服务端的密钥是怎么管理的，都有谁经手了，不小心泄露了呢？
- 浏览器这样的客户端是否可信任呢？里面会不会装了莫名其妙的插件钩子呢？
- 签发 https 证书的 CA 是不是足够可信任呢？

根据你的应用的敏感级别，这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1，意思就是你总是要多做一层防护，让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。

@dzdh 一个设计合理的请求签名算法中，所有有含义的请求参数都是被签名的对象，任何参数的修改都会导致签名失效，所以被拦截了也就只能重放那一个特定请求而已。更别说还有时间戳限制有效时间。总体原则就是，如果拦截不可避免，也要把损失降到最小

签名是一次性的，只针对这个请求，就算被截获了也伤害不大。密钥不管什么原因被泄露了，后续所有请求都可以伪造，所以能不暴露就不暴露，哪怕是加密通道