用于合并多个用户帐户的体系结构

Question

好的,我有一个网站,您可以自己注册并登录.您还可以使用您的Facebook,Twitter或linkedin帐户登录.

用户只注册一个帐户很重要.所以不知何故,我想合并用户的帐户,如果他们使用不同的方法登录.解决这个问题的最佳解决方案是什么？

例如,用户使用他的Facebook帐户登录.我使用这些数据自动为他注册一个帐户.我应该发送一封包含我们网站用户名和密码的电子邮件吗？(如果Facebook的政策没有问题).我应该给他们第二个屏幕,他们可以填写用户名和密码吗？但这并不是使用您的Facebook帐户登录的理念.它应该简化您的参与程序.

用户也可以在我们的网站上注册,并在下次使用他的Twitter帐户登录时.如何将这两个帐户合并为一个？什么是最好的方式？

基本上我的问题是:我有4种不同的方式,用户成为我们网站的成员.如果用户决定使用多种方式,我如何确保所有这4种方式只创建一个帐户？什么是最好的流程,以确保它不会成为用户自己的麻烦？

---

编辑:

在我提出这个问题3年后,我在一系列文章中给出了答案:http://www.sitepoint.com/series/using-social-networks-as-a-login-system/

Answer 1

我目前面临着完全相同的任务.我设计的设计相当简单,但效果很好.

核心思想是本地站点标识和第三方站点标识的模型保持隔离,但后来链接.因此,登录该站点的每个用户都具有本地身份,该身份可映射到任意数量的第三方站点身份.

本地身份记录包含最少的信息 - 它甚至可以是单个字段 - 只是一个主键.(对于我的申请,我不关心用户的电子邮件,姓名或出生日期 - 我只是想知道他们一直是登录此帐户的人.)

第三方身份包含仅与第三方身份验证相关的信息.对于OAuth,这通常表示用户标识符(如id,电子邮件或用户名)和服务标识符(指示通过身份验证的站点或服务).在应用程序的其他部分中,在数据库之外,该服务标识符与用于从该服务检索相关用户标识符的方法配对,并且这是如何执行认证的.对于OpenID,我们采用相同的方法,除了认证方法更通用(因为我们几乎总能执行完全相同的协议 - 除了我们使用不同的身份URL,这是我们的服务标识符).

最后,我记录了哪些第三方身份与当地身份配对.要生成这些记录,流程如下所示:

• 用户首次使用第三方身份登录.创建本地身份记录,然后创建第三方身份记录,然后将它们配对.
• 在控制面板中,用户可以通过登录第三方服务来链接帐户.(这非常简单.)
• 在用户无意中创建多个帐户的情况下,解决方案非常简单.当用户登录其中一个帐户时,他会登录到他之前用于登录站点的另一个帐户(通过上面的控制面板功能).Web服务检测到此冲突(登录用户的本地标识与链接到刚刚登录的第三方标识的本地标识不同),并且用户通过帐户合并提示.

合并帐户是合并本地身份的每个字段(根据应用程序而异,如果您的本地身份记录中只有几个字段,应该很容易),然后确保链接的第三方身份与最终的本地身份相关联.

Answer 2

我倾向于发现许多基于电子邮件合并的网站是重叠的连接因素.

我可以看到这是一个可行的选择,但这又取决于你对如何合并的偏好.电子邮件地址是人们用来验证网站上一些重要信息变更的主要方式,例如更改密码,终止服务,帐户余额等等......这几乎就像网络的社会安全号码系统但具有通信能力.文化上:我认为假设电子邮件在OAuth身份验证服务中是一个非常独特的身份是合理的.当然,这就是Facebook和Google要求的登录表单.

我目前的思考过程.

登录页面有3个选项

• 您自己的网站的会员资格
• 用facebook登录
• 用谷歌登录

1)首次用户登录:触发注册流程,首次创建并填充帐户.

 if the user logins using Facebook (or whatever 3rd party login)
      1) call the Facebook api asking for their information (email, name, etc...) 
      2) create an account membership entry in your database somewhat like this 

         Table = Users
         [ UserId   |       Email             | Password ]
         [    23     | "newuser@coolmail.com" |  *null*  ]

      3) create an external auths entry like so
         *ProviderUserId is the unique id of that user on the provider's site

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]

 if the user wants to create an account with your own registration it would just be this           

         Table = Users
         [ UserId   |       Email           |   Password  ]
         [    23     | newuser@coolmail.com |  myCoolPwd  ]

2)在其他时间,用户回来但决定点击Google登录

      1) call the Google api asking for their information (email, name, etc...) 

      2) once you get the email, match it up to the userId entry with the existing email 

      3) create an additional External auth entry as such

         Table = ExternalAuths
         [ ExternalAuthId  |  User_UserId   | ProviderName |   ProviderUserId  ]
         [    56           |      23        |   Facebook   |  "max.alexander.9"]
         [    57           |      23        |    Google    |  "1234854368"     ]

3)现在,您已合并了您信任的帐户,数据库条目上的电子邮件与您从外部登录信任的电子邮件相同.

因此对于后续登录

那么,如果您先拥有外部登录,然后您希望用户以后能够使用密码登录,该怎么办？

我看到两种简单的方法来做到这一点

• 在从外部身份验证创建帐户时首次登录时,要求他们输入密码以完成他们首次进入您的应用程序

• 如果他们已经使用Facebook或谷歌首先注册,那么不知何故想要使用您自己网站的注册表注册.检测他们输入的电子邮件地址是否已存在,询问他们是否有密码,并在注册完成后向他们发送电子邮件确认.

Answer 3

我已经通过sled.com了解了这一点.此处有关于创建帐户和支持多个第三方帐户进行登录的问题.他们之中有一些是:

• 您是否需要同时支持本地密码和第三方登录？

对于sled.com,我决定删除本地密码,因为它增加了一小部分密码以及保护密码输入表格的额外费用.有许多已知的破坏密码的攻击,如果你要引入密码,你必须确保它们不容易破解.您还需要将它们存储在单向散列或类似的东西中以防止它们泄露.

• 您希望在支持多个第三方帐户方面有多大的灵活性？

听起来你已经选择了三个登录提供商:Facebook,Twitter和LinkedIn.这很好,因为这意味着您正在使用OAuth并与一组明确定义的可信提供商合作.我不喜欢OpenID.剩下的问题是,您是否需要支持来自同一提供商的多个第三方帐户(例如,链接了两个Twitter帐户的一个本地帐户).我假设没有,但如果你这样做,你将需要在数据模型中适应它.

对于Sled,我们支持使用Facebook,Twitter和Yahoo!登录 并且在每个用户帐户中存储每个用户的密钥:{"_ id":"djdjd99dj","yahoo":"dj39djdj",twitter:"3723828732","facebook":"12837287"}.我们设置了一系列约束,以确保每个第三方帐户只能链接到一个本地帐户.

如果您要允许来自同一第三方提供商的多个帐户,则需要使用列表或其他结构来支持该帐户,并使用所有其他限制来确保唯一性.

• 如何链接多个帐户？

用户首次注册您的服务时,他们首先会转到第三方提供商并返回经过验证的第三方ID.然后,您为它们创建一个本地帐户,并收集您想要的任何其他信息.我们收集他们的电子邮件地址,并要求他们选择一个本地用户名(我们尝试使用其他提供商的现有用户名预填充该表单).使用某种形式的本地标识符(电子邮件,用户名)对于以后的帐户恢复非常重要.

如果浏览器没有现有帐户的会话cookie(有效或已过期),并且找不到使用的第三方帐户,则服务器知道这是首次登录.我们尝试通知用户他们不仅仅是登录,而是创建一个新帐户,这样如果他们已经有了帐户,他们就会希望暂停并使用现有帐户登录.

我们使用完全相同的流来链接其他帐户,但是当用户从第三方返回时,使用有效会话cookie的存在来区分尝试将新帐户链接到登录操作.我们只允许每种类型的一个第三方帐户,如果已经链接了一个,则阻止该操作.它应该不是问题,因为如果您已经有一个(每个提供商),则禁用链接新帐户的界面,但以防万一.

• 如何合并账户？

如果用户试图链接已经链接到本地​​帐户的新第三方帐户,您只需提示他们确认他们想要合并这两个帐户(假设您可以处理与您的数据集合并 - 通常更容易说比完成).您还可以为他们提供一个特殊按钮来请求合并,但实际上,他们所做的只是链接另一个帐户.

这是一个非常简单的状态机.用户使用第三方帐户ID从第三方返回.您的数据库可以处于以下三种状态之一:

1. 该帐户已链接到本地​​帐户,并且不存在会话Cookie - >登录
2. 该帐户已链接到本地​​帐户,并且会话cookie存在 - >合并
3. 该帐户未链接到本地​​帐户,并且不存在会话cookie - >注册

4. 该帐户未链接到本地​​帐户,并且存在会话cookie - >链接其他帐户

   • 如何与第三方提供商进行帐户恢复？

这仍然是实验领域.我还没有看到完美的用户体验,因为大多数服务都提供第三方帐户旁边的本地密码,因此专注于"忘记密码"用例,而不是其他可能出错的用例.

有了雪橇,我们选择使用"需要帮助登录？" 当您单击时,询问用户他们的电子邮件或用户名.我们查找一下,如果找到匹配的帐户,请通过电子邮件向该用户发送一个链接,该链接可以自动将其登录到服务中(一次有效).进入后,我们会将其直接带到帐户关联页面,告诉他们应该查看并可能链接其他帐户,并向他们展示他们已经关联的第三方帐户.

Answer 4

这两种自动合并帐户的方法都留下了相当大的漏洞,允许某人接管帐户.他们似乎都假设用户是他们在向注册用户提供合并选项时所说的用户.

我建议的缓解漏洞的方法是在执行合并之前请求用户与其中一个已知的身份提供商进行身份验证,以验证用户的身份.

示例:用户A注册Facebook身份.稍后他们会返回您的站点并尝试使用Windows Live ID访问并开始注册过程.您的网站将提示用户A ...看起来您之前已在Facebook注册过.请使用Facebook登录(提供链接),我们可以将您的Windows Live ID与现有配置文件合并.

另一种方法是在合并身份时用户必须提供的初始注册中存储共享密钥(密码/个人问题),但这会使您重新进入存储共享机密的业务.这也意味着您必须处理用户不记得共享密钥和随之而来的工作流的情况.