kejialiu

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