如果我要运行允许用户通过“本地”用户名/密码组合进行身份验证的服务以及任何数量的OAuth服务 - 该用户数据模型可能是什么样的？
通常，如果我自己处理所有登录，在“用户”数据库（假设MySQL）中，用户名和密码字段将被要求为非空。但是，如果我的用户只想登录Facebook，我只会存储Facebook自动令牌，而不是本地没有任何用户名/密码。
此外，如果他们想要使用Twitter信用卡登录，然后使用tumblr，然后进行任何当天的服务，该怎么办？我可以为每种类型保留一个字段，但这可能会有点笨拙。由于缺乏更好的术语，我是否会更好地保留另一个“身份验证方法”表格，因此我可以在用户之间建立一对多关系以及如何对其进行身份验证？
基本上，我问的是，是否有人知道这种情况的行业标准最佳实践，或者可以指出我正确的方向（或者如果某人已经实现了适合他们的这样的事情）。一个用户，多种身份验证方法 - 保存该信息的最佳方式是什么？
如果我所做的任何假设无效，我道歉，请纠正我。
答案 0 :(得分：8)
我不知道我的解决方案是否接近任何行业标准，但我之前已在多个应用程序中完成此操作。
应用程序中的身份应该来自身份验证源。 我最终设置的是这样的：
User table:
id int
username varchar
email varchar
password varchar
Authentication profile table:
user_id int
service enum('website','google','facebook')
token varchar
[为了进一步规范化，使用服务元字段使服务成为自己的表。 ]
然后你的auth脚本做了这样的事情：
在某些服务的情况下，您需要自动生成某些用户字段值，或者在第一次身份验证期间提示用户输入，具体取决于您从服务中获得的数据类型。
答案 1 :(得分：2)
我认为您想要的是本地身份验证系统（可能是出于遗留原因？）以及对使用委派身份验证登录的用户的支持。委托身份验证的标准是OpenID。您可能希望查看OpenID consumer libraries and samples，它可以让您了解存储OpenID凭据。不幸的是Facebook和Twitter不支持OpenID，但流程几乎相同，即您的数据模型不会改变。我们已经实现了一个OpenID使用者来支持基于OpenID的登录和注册。为了支持本地身份验证，我们使用了OpenID提供程序。换句话说，我们既是消费者又是提供者。这样，即使是本地auth系统也是基于标准的。现在回答关于架构的问题 - 我们将源（本地，推特，脸书，谷歌，雅虎，AOL）和电子邮件作为复合键，以及身份验证表中的令牌和/或密码。我们让用户更改他们的显示名称，并拥有一个独特的虚荣URL，这也是此模式的一部分。用户可以选择在通过OpenID进入时设置密码，对于Mobile，他们需要密码（而不是移动设备上的大量OpenID支持）。 OAuth解决了一个不同的用例，在这种情况下，您处理的是授权而不是身份验证。这有帮助吗？如果您有任何问题可以随时发表评论，我很乐意提供更多详细信息 - 我不想在此时向您提供太多信息。