我现在面临着完全相同的任务。我制定的设计相当简单，但效果很好。

核心思想是本地站点身份和第三方站点身份的模型保持隔离，但稍后链接。因此，每个登录网站的用户都有一个本地身份，该身份映射到任意数量的第三方网站身份。

本地身份记录包含最少的信息——它甚至可以是一个字段——只是一个主键。（对于我的应用程序，我不关心用户的电子邮件、姓名或出生日期——我只想知道他们是一直登录此帐户的人。）

第三方身份包含仅与第三方身份验证相关的信息。对于 OAuth，这通常意味着用户标识符（如
id、电子邮件或用户名）和服务标识符（指示哪个站点或服务已通过身份验证）。在数据库之外的应用程序的其他部分，该服务标识符与用于从该服务检索相关用户标识符的方法配对，这就是执行身份验证的方式。对于
OpenID，我们采用相同的方法，只是身份验证的方法更加通用（因为我们几乎总是可以执行完全相同的协议——除了我们使用不同的身份
URL，这就是我们的服务标识符）。

最后，我记录了哪些第三方身份与哪些本地身份配对。要生成这些记录，流程如下所示：

• 用户首次使用第三方身份登录。创建本地身份记录，然后创建第三方身份记录，然后将它们配对。
• 在控制面板中，用户有机会通过登录第三方服务来链接帐户。（这很简单。）
• 在用户无意中创建多个帐户的情况下，解决方案非常简单。当用户登录其中一个帐户时，他会登录另一个他以前用来登录网站的帐户（通过上面的控制面板功能）。Web 服务检测到这种冲突（登录用户的本地身份与链接到刚刚登录的第三方身份的本地身份不同）并提示用户合并帐户。

合并帐户是合并本地身份的每个单独字段（这会因应用程序而异，如果您的本地身份记录中只有几个字段应该很容易），然后确保链接的第三方身份与由此产生的本地身份相关联。