跨域登录 - 当用户从一个域转移到另一个域时如何自动登录
我们提供多种在线服务。 我们需要开发一个系统，当用户从一项服务（在 domain1.com 上）转移到另一项服务（在 domain2.com 上）时，该系统可为用户提供快速/简单的体验>）。
是否有一种安全可靠的方法可以让用户在转移到新服务后自动登录？
如果下面的解决方案完全不安全/错误，请对我大喊大叫。
我们正在考虑建立一个类似于许多在线密码恢复服务所提供的系统——他们会通过电子邮件收到一个带有唯一哈希值的链接，该哈希值会过期，允许他们更改密码。
domain1.com 站点将生成一个唯一的哈希值并将其存储在数据库中，该哈希值与过期日期时间字段一起链接到用户。
用户将被转移到 domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e
domain2.com 接下来将向 domain1.com 发出请求哈希来获取有关用户的信息。 然后，domain1.com 将从数据库中删除哈希值。 domain2.com 会让用户登录并设置 cookie 等。
基于 OpenID 或 OAuth 的东西可以达到相同的结果吗？
We offer a number of online services. We are required to develop a system which provides a quick/simple experience for users if they are transferred from one service (on domain1.com) to another service (on domain2.com).
Is there a safe and secure way to log a user in automatically once he has been transferred to the new service?
Yell at me if the solution below is completely insecure/wrong.
We were considering a system similar to that provided by a number of online services for password recovery - they are emailed a link with a unique hash which expires, that allows them to change their password.
The domain1.com site would generate a unique hash and store it in a database with the hash linked to a user along with an expire datetime field.
The user will be transferred to domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e
domain2.com would next make a request to domain1.com with the hash to get the information about the user. domain1.com would then remove the hash from the database. domain2.com would log the user in and set cookies, etc.
Could something based on OpenID or OAuth achieve the same results?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
单点登录 (SSO) 在概念上非常简单。
domain1.com。domain1.com发现没有会话 cookie。domain1.com重定向到sso.comsso.com显示登录页面，并获取凭据sso.com设置用户sso.com的会话 Cookie 然后重定向回domain1的特殊 URL（例如domain1.com/ssologinsso.com“签名”的参数。 它可以像使用共享密钥对登录 ID 进行 Base64 加密一样简单。domain1.com获取加密令牌，对其进行解密，使用新的登录 ID 登录用户。domain1为用户设置会话 cookie。现在，下一个案例。
domain2.com，它跟随domain1并重定向到sso.comsso.com已拥有 cookie对于用户，因此不会显示登录页面sso.com重定向回domain2.com，并使用加密信息domain2.com登录用户。这就是其工作原理的基本原理。 您可以使其更健壮，功能更丰富（例如，这是SSOn，但不是SSOff，用户可以“注销”
domain1，但仍登录到domain2）。 您可以使用公钥来签署凭据，您可以请求从 SSO 服务器传输更多信息（如授权权限等）。 您可以进行更密切的集成，例如域定期检查用户是否仍然拥有 SSO 服务器的权限。但使用重定向通过浏览器进行cookie 握手是所有这些 SSO 解决方案的关键基础。
Single sign-on (SSO) is conceptually pretty simple.
domain1.com.domain1.comsees there's no session cookie.domain1.comredirects tosso.comsso.compresents login page, and take credentialssso.comsets session cookie for the usersso.comthen redirects back todomain1to a special url (likedomain1.com/ssologin)ssologinURL contains a parameter that is basically "signed" by thesso.com. It could be as simple as a base64 of encrypting the loginid using a shared secret key.domain1.comtakes the encrypted token, decrypts it, uses the new login id to log in the user.domain1sets the session cookie for the user.Now, the next case.
domain2.com, which followsdomain1and redirects tosso.comsso.comalready has a cookie for the user, so does not present the login pagesso.comredirects back todomain2.comwith the encrypted informationdomain2.comlogs in the user.That's the fundamentals of how this works. You can make it more robust, more feature rich (for example, this is SSOn, but not SSOff, user can "log out" of
domain1, but still be logged in todomain2). You can use public keys for signing credentials, you can have requests to transfer more information (like authorization rights, etc) from the SSO server. You can have more intimate integration, such as the domains routinely checking that the user still has rights from the SSO server.But the cookie handshake via the browser using redirects is the key foundation upon which all of these SSO solutions are based.
如果有人能够扮演中间人并获取该哈希值，他们是否能够窃取跨域传输？ 显然，需要在客户需要使用它之前生成并发送给客户。 举例来说：
我扮演中间人监视杰克。
Jack 访问
domain1.com，这会导致准备好哈希并发送给他，以便当他访问domain2.com时，他可以发送该哈希作为身份验证。当他访问
domain1.com时，他的请求通过我发出，您返回页面，我获取哈希并让他继续。我使用哈希访问
domain2.com，您现在让我进入domain2.com并删除了哈希。直到他尝试登录
domain2.com并被告知他的凭据不再有效时，他才意识到这一点。你如何克服这个问题？
If someone were able to play man in the middle and grab that hash, would they be able to steal the cross domain transfer? Obviously it needs to be generated and sent to the client prior to them needing to use it. So say for instance:
I'm playing man in the middle spying on Jack.
Jack accesses
domain1.comwhich causes a hash to be prepared and sent to him so that when he accessesdomain2.comhe can send that hash as authentication.As he accesses
domain1.com, his request comes through me, you return the page, I grab the hash and let him carry on.I access
domain2.comusing the hash, you've now let me intodomain2.comand deleted the hash.He's none the wiser until he attempts to login to
domain2.comand is told that his credentials are no longer valid.How do you overcome that?
除非您在整个会话中使用 SSL，否则使用 SSL 进行跨域登录没有任何意义。 窃取会话 cookie 与在 url 中使用哈希值一样容易。 如果会话的其余部分不安全，那么在 SSL 中隐藏哈希值有什么意义呢？
顶部给出的方法几乎是标准方法。 是否选择使用安全协议完全是另一回事，但仅加密部分会话是没有意义的。
There wouldn't be any point using SSL for the cross-domain login unless you use SSL for the entire session. It is just as easy to steal a session cookie as it is to use a hash in an url. What is the point in hiding the hash in SSL if the rest of the session is insecure.
The method given at the top is pretty much the standard method. Whether you choose to use secure protocols is another matter entirely, but it would be pointless to only encrypt part of the session.
这是一个很好的解决方案。 这里有两点需要考虑：
您使用术语“散列”，但不清楚您将散列哪些数据。 相反，请使用“随机数”：由加密质量 RNG 生成的大（128 位）数字。
此外，您没有指定这一点，但用户与两个域之间以及域本身之间的通信必须是安全的。 使用 SSL 对服务器进行身份验证并对随机数保密。
This is a good solution. Here are two points to consider:
You use the term "hash", but it's not clear what data you'll hash. Instead, use a "nonce": a large (128-bit) number generated by a cryptographic quality RNG.
Also, you didn't specify this, but communications between the user and both domains, and between the domains themselves, must be secure. Use SSL to authenticate the servers and to keep the nonce confidential.
搜索引擎优化怎么样？
看起来成功登录之前的每个请求都被重定向到其他域并返回。
我想说这非常丑陋。
您应该发送哪些标头？ 301 到 SSO，然后返回 301 到原始页面？ 那么搜索机器人被“要求”两次更改该页面的索引？
What about SEO?
It looks like every request before succesfull login is redirected to other domain and back.
I would tell that this is very ugly.
What headers should you send? 301 to SSO and then back 301 to original page? So search bot is "requested" to change his index for that page twice?