我正在开发一种 SSO 解决方案，其中有一个主身份验证站点和多个从属站点。我正处于当有人在从服务器上注册时需要将注册转发给主服务器并随后将用户登录到主服务器的地步。
有很多方法可以解决这个问题，目前我正计划加密所需的注册/登录数据，并在隐藏的 iframe 中使用这些数据重定向最终用户，这样最终用户就不会被这个过程打扰(这将包含在网站 T&C 中)。现在它已经在使用 SSL，但我想让这个过程尽可能安全。目前，我正在使用主设备和从设备都在其配置中保存的 key 对发送的数据进行加密。我担心有人可能会破解这个，因为 key 总是相同的，并且我正在考虑使用 salt 以及主服务器必须从每个单独查询从从服务器获得的 key ，但这会加倍所需的 HTTP 查询量。
我只是想知道我是想多了，还是太谨慎了(毕竟，理论上 SSL 本身就足够了)。
有什么建议吗？谢谢
最佳答案
在大多数情况下，SSL 应该足够了。如果服务器的证书和私钥存储安全，定期检查证书吊销，私钥不弱(等等......)，最终用户浏览器和你的服务器之间的 channel (以及之间的 channel ) master 和 slave 站点)将防止窃听，防止其他人看到凭据。
SSL 不做的是验证连接的“客户端”端，也就是说，任何知道正确 URL 的人都可以连接、验证(模拟从属站点)并获取验证/登录 token (如果 提供的凭证是正确的)。这意味着，给定一个 token ，您的主服务器将无法区分哪个站点正在执行“特权”功能。凭据本身仍受 SSL 保护，攻击者仍需要知道它们才能执行攻击。 (我假设网站本身没有其他错误，例如 XSS 漏洞或不正确的 cookie 管理)。
就是说，如果您需要管理此网络内部的权限，您应该使用 key (或字符串形式的 secret )并将其从从站点传递给主站点非常详细(例如根据用户的身份阻止登录某些网站并允许其他网站登录，或者如果某些网站不受您的直接控制并且您怀疑妥协，则暂时拒绝登录某些网站)；如果是这样的话，我建议你看看 OAuth site ，这是一个专门为此目的而设计的协议(protocol)(您可以简单地编写一个允许登录并从主服务器检索必要数据的 API)。
如果(且仅当)所有站点都在您的直接控制之下，则仅使用 SSL 就足够了；管理两组 key (一组用于 SSL，一组用于额外加密)的负担太重，而且服务器会占用太多资源。仅确保浏览器和服务器之间以及服务器本身之间的所有通信都使用 SSL，以防止网络嗅探。
关于php - 通过 HTTP 跨域安全地发送数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9446847/