跨域登录 - 如何在从一个域转移到另一个域时自动登录用户 [英] Cross Domain Login - How to login a user automatically when transferred from one domain to another

问题描述

我们提供一些在线服务。如果从一个服务（ domain1.com ）转移到另一个服务（在$ $ c上），我们需要开发一个为用户提供快速/简单体验的系统$ c> domain2.com ）。

有一种安全可靠的方式，一旦他被转移到新服务？

如果下面的解决方案完全不安全/错误，对我来说。

我们正在考虑系统类似于许多在线服务提供的密码恢复 - 它们通过电子邮件发送一个具有唯一哈希值的链接，该密码可以过期，允许他们更改密码。

domain1.com 将生成唯一的哈希，并将其存储在数据库中，并将哈希链接到用户以及到期日期时间字段。

用户将被转移到 domain2.com/auto/?hash=d41d8cd98f00b204e9800998ecf8427e

domain2.com 会xt通过哈希请求 domain1.com 以获取有关用户的信息。 domain1.com 然后将从数据库中删除哈希。 domain2.com 将登录用户并设置cookie等。

可以基于OpenID或OAuth的内容实现相同的结果？

解决方案

单点登录（SSO）在概念上很简单。

• 用户点击 domain1.com 。


• domain1.com 看到没有会话cookie。


• domain1.com 重定向到 sso.com


• sso.com 呈现登录页面，并获取凭据


• sso.com 设置用户的会话cookie


• sso.com 然后重定向到 domain1 到一个特殊的url（像 domain1）。 com / ssologin ）


• ssologin URL包含基本上被签名 code> sso.com 。它可能与使用共享密钥加密loginid的base64一样简单。


• domain1.com 采用加密令牌，解密它，使用新的登录ID登录用户。


• domain1 为用户设置会话cookie。 >
  

现在，下一个例子。

• 用户命中 domain2.com ，它遵循 domain1 并重定向到 sso.com


• sso.com 已经有用户的cookie，所以不出现登录页面


• sso.com 重定向到 domain2.com 加密信息


• domain2.com 登录用户。

这是如何工作的基础。您可以使其更强大，功能更丰富（例如，这是 SSOn ，但不是 SSOff ，用户可以注销 domain1 ，但仍然登录到 domain2 ）。您可以使用公钥签名凭据，您可以要求从SSO服务器传输更多信息（如授权权限等）。您可以进行更贴切的整合，例如域名通常会检查用户是否仍然拥有SSO服务器的权限。

但是， cookie握手通过使用重定向的浏览器是所有这些SSO解决方案基础的关键基础。

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 automatically login a user 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 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 cookie etc.

Could something based on OpenID or OAuth achieve the same results?

解决方案

Single sign-on (SSO) is conceptually pretty simple.

• User hits domain1.com.
• domain1.com sees there's no session cookie.
• domain1.com redirects to sso.com
• sso.com presents login page, and take credentials
• sso.com sets session cookie for the user
• sso.com then redirects back to domain1 to a special url (like domain1.com/ssologin)
• the ssologin URL contains a parameter that is basically "signed" by the sso.com. It could be as simple as a base64 of encrypting the loginid using a shared secret key.
• domain1.com takes the encrypted token, decrypts it, uses the new login id to log in the user.
• domain1 sets the session cookie for the user.

Now, the next case.

• User hits domain2.com, which follows domain1 and redirects to sso.com
• sso.com already has a cookie for the user, so does not present the login page
• sso.com redirects back to domain2.com with the encrypted information
• domain2.com logs 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 to domain2). 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.

这篇关于跨域登录 - 如何在从一个域转移到另一个域时自动登录用户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！