在 2 个单独的域上进行身份验证（设置 cookie）

Question

如果你们对此有任何想法/见解，我将不胜感激......

我有两个域运行相同的应用程序，例如mysite.com 和 mysite.org，我有一个要求，当用户登录 mysite.com 时，他也应该登录到 mysite.org。显然，我不能在另一个域上设置 cookie，但我想提出一个合理、安全 的解决方案。我想我有一个解决方案（在纸上），但我只是想要一些关于如何改进和保护它的反馈。

我的会话表目前如下所示：

id: auto-incrementing; only used for by ActiveRecord
uuid: Universally Unique Identifier used for session lookup
user_id: the user this session belongs to
user_ip_address: the user's IP address
created_at: self-explanatory
updated_at: self-explanatory

我目前在 one 域上进行身份验证的逻辑：

1. 用户尝试访问 mysite.com/some_protected_info；他们没有经过身份验证，因此他们被重定向到登录页面（推荐 URL 存储在 cookie 中）
2. 用户在 mysite.com 上成功验证；在数据库中创建一个会话；为 mysite.com 创建一个 cookie；用户被重定向到 cookie 中的推荐 URL，即 mysite.com/some_protected_info。

我提出的在两个域上进行身份验证的逻辑：

1. 用户尝试访问 mysite.com/some_protected_info；他们没有经过身份验证，因此他们被重定向到登录页面（推荐 URL 存储在 cookie 中）
2. 用户在 mysite.com 上成功验证；在数据库中创建一个会话；为 mysite.com 创建一个 cookie；然后将用户重定向到 mysite.org，例如mysite.org/login/special
3. 登录控制器的特殊操作会查找会话，发现会话有效并在 mysite.org 上设置 cookie 并重定向回 mysite.com 上的另一个控制器操作。
4. 鉴于用户在 mysite.com（可能是 mysite.org）上经过身份验证，用户将被重定向回推荐 URL (mysite.com/some_protected_info)。

注意： - 两个站点都使用 SSL。 - 两个站点都使用完全相同的代码（mongrel 实例） - Apache 配置使其可以通过不同的域访问，即两个域上的 config.action_controller.session 设置完全相同。

问题：

在 (2) 中，我应该通过 SSL 传递 UUID 还是出于安全考虑？我应该生成一个新的、随机的临时 ID 来查找会话吗？

在 (3) 中，我应该传递引荐 URL (mysite.com/some_protected_info) 还是仅重定向回 mysite.com 上 cookie 的值是否安全？

有什么问题吗？我忽略的特殊情况？

Answer 1

跨域工作的登录系统的简单设计取决于它们是单一的身份验证点，其他域可以使用它来验证会话信息。

通常，登录机制是受 HTTPS 保护的页面，能够验证凭据并发出可远程验证的会话 ID。在实践中，一个域会将访问者转发到登录页面进行身份验证，然后登录过程会将访问者重定向回原始站点，并传递某种会话 ID 参数，该参数可以通过以下方式分配给 cookie原始网站。

对于仅具有中等安全要求的应用程序，可以使用登录系统和其他域都知道的“密钥”对会话 ID 值进行加密或散列。这用于证明用户的会话 ID 是由登录系统发出的，而不仅仅是任意的。这与出于验证目的使用盐对密码进行哈希处理没有什么不同。

虽然 UUID 看起来足够独特，但生成器可能会生成可预测的数字，或者随机性不足的数字。这就是为什么发送“签名”值对于排除欺骗很有用。

您的想法似乎相当可靠，但细节很重要。可能值得研究 OpenID 之类的东西，了解它们如何通过其协议处理会话身份验证。

Answer 2

这不是一个真正的答案，但如果您拥有这两个域，则可以使用 cookie 跨域策略设置您的 cookie：

例如，您可以在 yourdomain.com 上创建一个 crossdomain.xml：

<?xml version="1.0" ?>
<cross-domain-policy>
  <allow-access-from domain="yourdomain.org" />
</cross-domain-policy>