如何在没有 sso 服务器的情况下实现基于 cookie 的单点登录？ 我会使用共享跨多个应用程序登录的用户 只是浏览器上的一个cookie。
在我看来它是这样工作的：
在此解决方案中，用户可能会看到（另一个用户的）浏览器 cookie 并获取用户名编码的字符串。然后他可以添加它 自己的 cookie（不好！）。
有一些安全的方法可以做到这一点吗？使用基于时间戳的控件或 像这样？
提前致谢。
再见
附： 我知道我的英语不是很好.. 很抱歉！
【问题讨论】：
标签： single-sign-on
这是不可能的。每个域的 Cookie 都是唯一的，一个域无法读取另一个域的 cookie。
【讨论】：
foo.example.com 和 bar.example.com 可以共享一个 .example.com cookie。
我认为答案来的有点晚，但也许我可以帮助某人。
您可以在使用 iframe 连接到主页的中间域中拥有一个 cookie / localStorage
1) 登录 您的任何域中的登录表单通过事件 (postMessage) 将标识令牌存放在 sso.domain.com 上的 cookie 中 2) 验证 domain1 和 domain2 包含一个指向 sso.domain.com 的 iframe，它读取令牌并通知主页
为了简化开发，我们最近在https://github.com/Aralink/ssojwt发布了一个带有 JWT 的跨域 SSO
【讨论】：
有一个简单的解决方案，不使用 sso 服务器，但不使用 1 个通用 cookie，因为我们知道 cookie 不会在域之间共享。
当用户在 site-a.com 上进行身份验证时，您在 site-a.com 域上设置了一个 cookie。然后在 site-b.com 上，链接来自 site-a.com 的动态 javascript，由有权访问创建的 cookie 的服务器端脚本（php 等）生成，然后在 site-b.com 上复制相同的 cookie在客户端使用js。现在两个站点都有相同的cookie，不需要要求用户重新登录。
您可以使用站点 a 和站点 b 都知道如何解码的方法对 cookie 值进行加密/编码，以便站点 b 能够验证他的 cookie 副本。使用一个共同的共享秘密，没有它就不可能编码或解码。
您看到在 site-b.com 的第一个页面加载时，cookie 不存在，因此如果您认为有必要，您可能希望在设置 cookie 后重新加载页面。
【讨论】：
http only
我做过类似的事情。有一个 PHP 应用程序，用户在其中登录，系统联系 Web 服务，然后该服务检查用户在 Active Directory 上的凭据。当用户通过身份验证时，他的 PHP 会话存储在数据库中。另一个 Web 应用程序可以从 cookie 中读取 PHP 会话并使用 PHP 应用程序中的 Web 服务，PHP 应用程序检查数据库中的会话并返回用户 ID。这样我就有了一个使用 SOA 的 SSO。
不要依赖存储在浏览器中的用户id，是安全错误，至少要加密id。
最好的解决方案是将登录表单和会话存储放在同一个应用程序中，然后该应用程序可以为其他应用程序提供服务。
并使用 HTTPS 进行信息交换。
cookies只有在属于同一个域的情况下才能读取，例如：
intranet.example.com crm.example.com example.com/erp
【讨论】：
您可以跨子域访问 cookie，但我不认为使用浏览器 cookie 是一个很好的解决方案。您确实不需要“SSO 服务器”来实现单点登录。想出一个两个应用程序都能识别的有效负载是相当容易的。我见过使用 XML 通过 HTTPS 传输有效负载的自定义 SSO 解决方案。
【讨论】：
这里有一个解决方案（希望在这里得到安全专家的严格审查）：
让每个域将用户数据存储在类似的 cookie 中，当用户想要从一个域跳转到另一个域而不在新域上进行身份验证时，请在查询字符串中提供带有加密令牌的“跳转链接”。新域将解密 cookie，并确定用户是谁，然后向他们发出该域的新 cookie。您会希望“跳转链接”的到期日期非常短，因此我不会将它们直接生成到页面中，而是生成指向“跳转链接”生成器和重定向器的链接。
这可能不是必需的，但“跳转链接”的接收页面可以向原始域发起 Web 服务回调，以验证加密令牌的真实性以及它是否已过期。
我认为这种解决方案容易受到中间人攻击（不确定它是否比当前流行的其他身份验证机制更容易受到攻击），但您可以将客户端 MAC 地址和 IP 地址合并到加密令牌以提高安全性。
【讨论】：