为什么两个 Web 应用程序之间使用带有查询参数的重定向或自动表单发布的数据交换不能被每个 Web 应用程序信任，即使使用 HTTPS 也是如此？
注：
我了解使用查询参数的数据交换具有固有的安全性风险，例如CSRF、通过浏览器历史记录和访问日志泄露数据，以及auto-form-post具有固有的CSRF安全风险。不过，这不是这里讨论的重点。当前的问题是，“为什么每个 Web 应用程序不能信任交换的数据，即使使用 HTTPS？”
用例： 考虑在 https://one.abc.com 和 https://two.xyz.com 上运行的两个 Web 应用程序。他们都希望交换数据，但无法直接通信。
详细流程： 访问 https://one.abc.com 时，页面会显示一个按钮。单击后，它会提交到 https://one.abc.com，然后重定向到 https://two.xyz.com。在 https://two.xyz.com 上，存在另一个按钮，单击该按钮后，会提交到 https://two.xyz.com 并重定向到 https://one.abc.com。
由于一切都通过 HTTPS 进行，因此所有元素（包括 URL、查询参数和标头）都会在重定向期间加密。
通过此设置，可以使用查询参数或自动表单发布来实现两个 Web 应用程序之间的数据交换。
但是，为什么即使使用 HTTPS，每个 Web 应用程序也不能信任交换的数据？
简单来说，在第一步中，如果
https://one.abc.comhttps://two.xyz.comhttps://two.xyz.comhttps://one.abc.com类似地，在第二步中，如果
https://two.xyz.comhttps://one.abc.comhttps://one.abc.com https://one.abc.com上述技术用于 SAML、OIDC 中的 SSO。
请告诉我以下理解是否正确：
在所描述的从
one.abc.comtwo.xyz.comone.abc.com从
one.abc.comtwo.xyz.comone.abc.comone.abc.comone.abc.comtwo.xyz.comtwo.xyz.comtwo.xyz.com从
two.xyz.comone.abc.comtwo.xyz.comtwo.xyz.comtwo.xyz.comone.abc.comone.abc.comone.abc.com每个连接（从您的浏览器到
two.xyz.comone.abc.com但是，在重定向流程期间，
two.xyz.comone.abc.com因此，在 SAML 中，IDP 签署
SAML assertionid_token在我看来，必须发生两件事才能建立安全连接：
如果没有这两个条件（也许更多？），就没有什么可以阻止客户端嗅探/拦截两个服务器之间流动的数据