咱们先把场景和核心问题明确下来：假设你有两个独立的Web应用，分别部署在one.abc.com和two.xyz.com上，它们没法直接通信，只能通过用户浏览器的重定向或自动表单提交来交换数据，而且全程使用HTTPS加密。你已经排除了CSRF、数据泄露这类风险，现在聚焦的核心问题是：为啥接收方就是没法信任收到的数据确实来自对方应用？

先搞懂HTTPS在这里的局限 #

HTTPS的作用是保障浏览器和单个服务器之间的通信安全：它能加密传输内容，防止中途被窃听，也能验证服务器身份、保证传输的数据没被篡改。但在你说的重定向/表单POST流程里，两个应用之间根本没有直接的TLS连接——所有数据都是通过用户的浏览器中转的，咱们拆解一下完整流程就懂了：

从one.abc.com到two.xyz.com的流程

• 用户在one.abc.com点击按钮，浏览器和one.abc.com建立单独的HTTPS连接，提交请求
• one.abc.com返回重定向指令（比如HTTP 302），告诉浏览器去访问two.xyz.com
• 浏览器断开和one.abc.com的连接，重新和two.xyz.com建立全新的HTTPS连接，把带数据的请求发过去

从two.xyz.com回到one.abc.com的流程

• 用户在two.xyz.com点击按钮，浏览器和two.xyz.com建立单独的HTTPS连接，提交请求
• two.xyz.com返回重定向指令，告诉浏览器去访问one.abc.com
• 浏览器断开和two.xyz.com的连接，重新和one.abc.com建立全新的HTTPS连接，把带数据的请求发过去

核心问题：接收方无法验证数据的真实来源 #

在这个流程里，two.xyz.com只能确认：当前收到的请求是浏览器通过安全的HTTPS通道发过来的，但它没法证明这些数据真的是one.abc.com生成的——因为攻击者完全可以直接构造一个指向two.xyz.com的HTTPS请求，带上伪造的数据，two.xyz.com根本区分不出这是正常中转的请求，还是攻击者伪造的请求。

反过来，当two.xyz.com通过重定向给one.abc.com发数据时，one.abc.com也面临同样的问题：只能确认请求来自安全的HTTPS连接，但没法验证数据确实来自two.xyz.com。

你的理解完全正确！ #

你对TLS连接的拆解是准确的：每个HTTPS连接都是浏览器和单个服务器独立建立的，两个应用之间没有直接的加密通信链路，数据必须经过浏览器这个中间节点，这就导致接收方无法直接确认数据的真实来源。

这也是为啥SAML、OIDC这类SSO协议会采用签名机制：身份提供者（IDP/OP）会对SAML assertion或者id_token进行数字签名，接收方可以通过预先约定好的公钥验证签名，从而确认数据确实是合法的发送方生成的，没有被篡改过——这才建立了跨应用的数据信任。

备注：内容来源于stack exchange，提问作者mee