用于多种身份验证的数据库模式、Facebook Connect、Twitter、OpenID 等答案

【问题标题】：Database Schema for multiple authentications, Facebook Connect, Twitter, OpenID, etc用于多种身份验证的数据库模式、Facebook Connect、Twitter、OpenID 等
【发布时间】：2011-04-18 13:55:02
【问题描述】：

我正在构建一个应用程序，我想与 Facebook Connect、Twitter、OpenID 和可能的其他社交网络进行交互。用户将能够同时使用任意数量的这些方法登录。我的应用程序使用 MySQL 作为后端数据库。

有人可以指导我同时从各种社交网络捕获用户信息的数据库架构应该是什么样的吗？我有一个想法（基于我的在线阅读）是这样的：

用户 {userid, ...}
UserFacebook {fbid, userid, ...}
UserTwitter (twid, userid, ...}
等等等等。

然后，为了全面了解用户，我将加入所有用户表。这是其他网站的做法还是有更聪明/更好的方法？

【问题讨论】：

标签： database-design facebook openid twitter

【解决方案1】：

我建议您将用户架构放在两个表中：用户和身份。身份应该有：Id、User Id、Adapter、Hash。

对于用户名/密码认证适配器，Hash 将是一个散列（例如 MD5/SHA1）密码，而其他适配器（Facebook、Twitter 等）将是 Auth Provider 提供的令牌。

祝你好运。

【讨论】：

有点旧的答案，但即使在 2011 年，直接对密码进行 MD5/SHA1 哈希也是一种不好的做法。
@Craig 是的。这只是一个例子。
人们从字面上看例子。
我正在考虑更多类似 salted scrypt、bcrypt 或 pbkdf2 的东西。

【解决方案2】：

这就是我所做的，我将帐户表与身份验证过程分开，例如该帐户可能包含帐户名称、注册日期和唯一 ID。然后我可以创建 4 个附加表，例如：users_openid、users_facebook、users_twitter 和 users（用于您的正常用户名/网站身份验证），它们都有一个链接到帐户表的外键 (account_id)。

这样您就可以将用户登录系统的方式与实际帐户的方式分开。

【讨论】：

将用户拆分到四个表中绝对是个坏主意。
@deanWombourne 我上面的回答解释了我认为更好的地方。