我正在尝试让使用我们服务的用户不必拥有多个帐户/密码。我所在的大型组织有一个小组负责处理来自机构外部的用户的部分用户身份验证（主要用于管理功能）。他们存储安全 cookie 以建立会话，并仅通过浏览器通过 HTTPS 进行通信。会话到期的原因有：1) 用户明确注销 2) 不活动 3) 浏览器关闭
我的团队正在尝试编写一个 Web 应用程序来帮助用户分析他们在我们设施内获取的（或当前正在获取的）数据。我们需要确定用户是否 1) 经过身份验证 2) 是否有该用户的某些标识符，以便我们可以存储他们的状态（他们正在进行的分析等）
因此，问题在于如何跨域进行身份验证（其他应用程序的身份验证服务器位于公共和私有之间的边界区域 - 我们将位于公共区域）。
我们已经想出了一些方案，我希望得到有关最佳做法的建议，或者是否存在我们尚未考虑到的做法。
让我们从用户通过认证服务器进行认证的情况开始。
1) 身份验证服务器在浏览器中留下一个公共 cookie，其中包含用户的主密钥。如果这被视为敏感信息，他们会在其服务器上对其进行加密，而我们则拥有在我们的服务器上解密的密钥。当用户访问我们的网站时，我们会检查此公共 cookie。我们提取 user_id 并使用公共 api 让身份验证服务器请求用户是否已登录。如果已登录，他们会向我们发送以下响应：
response={ userid ：然后我们可以将其映射到我们自己的用户 ID。如有必要，我们可以请求一次其他信息，例如电子邮件地址/显示名称（如果长时间运行的工作已完成，则通知他们，或与其他人共享结果，例如使用 google_docs）。 account_is_active：确保帐户仍然有效 session_is_active：他们的会话是否仍然有效？如果我们查询有效用户，这将产生副作用，我们将重置 last_time_session_activated 值，从而延长他们与身份验证服务器的会话 last_time_session_activated：让我们知道他们还剩多少时间 ip_address_session_started_from：确保我们网站上的人来自他们开始会话的同一 ip }
收到此响应后，我们要么接受它们已通过身份验证并继续使用我们的应用程序，要么将它们重定向到身份验证服务器的登录页面（问题：如果我们提供响应的加密部分（由我们签名）以及将它们重定向到的页面，我们会在身份验证服务器中打开任何巨大的安全漏洞吗）？
我们发现这个缺陷是，如果用户访问 evilsite.com 并且他们查看会话 cookie 并向身份验证服务器的公共 API 发送查询，他们可以保持会话处于活动状态，如果我们的原始用户离开机器而没有注销，那么下一个用户将能够访问他们的会话（这在以前是可能的，但是让会话永远处于活动状态会使情况变得更糟）。
2) 身份验证服务器将对我们域的所有请求重定向给我们，然后我们通过它们将响应发送回用户。本质上，它们充当代理。这样做的好处是我们可以与身份验证服务器握手，因此可以安全地信任用户的电子邮件地址/姓名，他们不必重新输入
因此，如果用户尝试访问：authentication_site/mysite_page1，他们将被重定向到 mysite。
您会选择哪种方式，或者有更好的方法吗？目标是尽量减少“又一个密码/又一个用户名”问题...
谢谢！！！！
答案1
这非常抽象，所以这将是一个抽象的答案。
这里有两个问题。身份验证和授权，通常缩写为 authn（身份验证）和 authz（授权）。身份验证是验证用户的身份，授权是允许他们根据自己的身份做事。AuthN 是第一个，其次是 AuthZ。
鉴于您是 ServerFault 的注册用户，您已经遇到了一种使用单个域 AuthZ 处理多个域 AuthN 的方法。它被称为 OpenID，旨在解决您所描述的问题。用户使用 OpenID 提供商（例如 google 或 yahoo）进行身份验证，依赖方（ServerFault）接受用户已通过身份验证并据此提供授权。ServerFault 不处理密码。
这里的诀窍是将 authn 与 authz 分开。如果您可以说服您的环境允许这样的事情，您的工作就会变得容易得多。您甚至可以使用 OpenID，因为依赖方可以限制他们信任的提供商。
答案2
答案3
我的团队正在尝试编写一个 Web 应用程序，以帮助用户分析他们在我们设施内获取的（或正在获取的）数据
嗯？你的意思是你想审计所有数据访问？还是你只想分析使用情况？它们完全不同 - 前者必须与身份验证紧密结合 - 但这需要付出大量处理的代价。
如何跨域验证
有很多文档描述了如何使用 cookie 实现 Web 会话的 SSO。
您的建议使系统完全暴露在重放攻击之下，并且根据我的理解，它依赖于所有应用程序都被提供相同的 cookie（意味着应用程序都在同一个虚拟主机上，或者您正在尝试使用第三方 cookie - 这是一个非常糟糕的主意）。
如果用户访问 evilsite.com 并查看会话 cookie
因此，您正在使用第三方 cookie - 这不仅是一个巨大的安全漏洞，而且它不能在所有浏览器上移植 - 甚至特定的浏览器也会因配置而异。
（如果您尝试分析/审计使用情况，为什么要尝试创建 SSO 系统？）
用于会话的代理标识符（通常是会话 cookie）必须是随机值 - 使用可逆加密有一些原因，但很容易出错，从而暴露您的密钥 - 然后您的安全就完蛋了。为了避免固定问题，必须为每个应用程序独立（重新）生成这些在会话通过身份验证时并在会话终止时被覆盖 - 这意味着您的应用程序需要在会话（重新）生成时回发到某个中央存储库（注意：我在这里谈论的是服务器到服务器的消息 - 而不是通过客户端）。身份验证服务器应通过 url 查询参数将身份验证状态连同操作的序列号一起发送到应用程序 - 例如在重定向中（使用加盐哈希来验证信息 - 使用盐作为共享密钥）。再次，应用程序应回发（服务器到服务器）用户已通过身份验证和序列号（以提供额外的重放保护），并在向客户端发布新的会话标识符之前检查身份验证服务器是否正常。
Cookie 应仅限于 HTTP - 并且优先标记为仅 SSL。并且它不仅应限制在规范域中，还应限制在应用程序的路径中。