我已经为我们的网络构建了一个单点登录系统。它是这样工作的：
- 用户点击他想要登录的站点（“不安全站点”）上的登录链接。不安全站点的 ID 在 URL 中传递。
- 他最终进入了系统（称为“RAS”）的登录页面。这是在它自己的域上，并且将来可能会获得 HTTPS，因此用户可以看到他的数据是安全的。
- 用户登录。在保存用户 ID、不安全站点 ID 和到期时间的服务器上进行“会话”。
- 用户的浏览器被重定向回不安全的站点。新创建会话的 ID 作为 URL 参数传递。
- 不安全站点向 RAS 发送用户数据请求。它包括会话 ID 和一些凭据，这些凭据将识别和验证 RAS 上的不安全站点。（请注意，用户和他的浏览器完全被排除在外）
- 用户的数据（没有密码）被返回到不安全的站点。然后，不安全的站点将其存储在它自己的会话中，或者其他什么都没有关系。
（要查看它的实际效果，请访问例如 cncguild.net 并单击顶部附近的登录链接）
如您所见，这是非常安全的。不安全的站点在任何时候都无法访问用户的密码。
但是，关于可用性，我们希望更好地将登录过程与不安全的站点集成。这样做的方法是，而不是做整个“发送到登录页面并重定向回来”，而是打开一个弹出窗口。我目前看到三种可能的方法来做到这一点：
使用登录表单添加覆盖 div。使用 AJAX 与 RAS 通信，直到登录完成并且客户端代码收到会话 ID。然后它可以通过将此会话 ID 发送到它自己的服务器端代码（通过刷新或 AJAX）来处理用户数据的获取。虽然这会带来最佳的可用性，但也存在一些巨大的安全隐患：
- 不安全站点的 Javascript 可以访问密码
- 虽然用户可以检查源以查看它是否试图窃取它，但谁在认真地这样做呢？
不要将表单放在同一个 HTML 文档中，而是让覆盖 div 包含一个带有登录页面的 iframe。
- 这会隐藏不安全站点的密码（如果浏览器具有不错的 iframe Javascript 安全策略）
- 没有明显的浏览器界面标记可以向用户显示它是这样的。因此，恶意的不安全站点作者可以构建自己的登录表单副本，该副本看起来完全相同，但实际上不在 iframe 中。
- 除了刷新之外，没有办法将会话 ID 传回不安全的站点。不可能在不安全的站点上进行花哨的 AJAX 登录。
在真实弹出窗口中打开登录页面（window.open）
- URL 和 HTTPS 图标清晰显示
- 它可能真的很丑。我不确定可用性相对于它现在的工作方式是否真的有很多好处。
您对这三个选项中的每一个都有什么看法？当然，我期待第一个选项的嘲笑。它把安全撕成碎片。为了完整起见，我将其包括在内。也欢迎更多选择