我即将构建一个新的 Web 应用程序，但我正纠结于要支持的身份验证系统。
过去，创建注册页面并将所有内容与您自己的自定义身份验证提供程序绑定在一起是一件简单的事情。现在有 OpenID、Facebook Connect、Twitter，现在我正在阅读有关OpenID Connect - OAuth 的包装器。
因此，面对必须适应越来越多的身份验证协议的前景，我想知道哪些（即“Open-X”品种）是“必备品”，哪些只是“肉汁”。
此外，拥有自己滚动的注册表单是否仍然被认为是一种好的做法，或者现在期望用户使用谷歌、Facebook 或其他一些变体登录是否可以接受？
这个问题是在问一个类似的问题，期望只选择一种机制。我不相信这是最具包容性的方法，但支持一切肯定是不切实际的。
我认为对于开发人员类型的网站，SO 是选择 openid 的最佳选择。有技术倾向的人几乎可以立即掌握 openid。IMO，如果您有一个一般网站，技术上不倾向于访问的人正在访问他们可能无法立即获得它，并且可能会选择去其他网站。我说，让用户在您自己的注册系统和 openid 之间进行选择——这样您就不会吓到非极客。我有一个通用网站，看到人们通常选择openid登录。希望有帮助
我是 OpenId 的忠实粉丝——它对技术人员有好处，但对 mroe 普通用户来说则不然。只有当我们了解您的听众时，才能回答您的很多问题。如果您的用户也可能在 Facebook 上显示技术较少的受众，那么这可能是默认情况下使用 OpenId 作为辅助机制的方式。恕我直言，如果您在 Twitter 上，那么 OpenId 不应该有任何恐惧，三种机制至少是一二多。
至于您滚动自己的登录页面 - 为什么需要它？如果您要让其他人处理登录，这只是另一个要编码的页面，为什么还要创建自己的。
This depends on what your requirements are - your reason for authenticating users, and what you can expect your users to understand and be willing to use.
In general, though, go with what's popular, because you'll benefit from more robust libraries, eyes looking at the security implications, and available service providers. Assuming you want single-sign-on, this currently seems to be either OpenID+OAuth, or OAuth WRAP. This can be subject to opinion; I recommend looking for identity-centric tech blogs and lists to see what's being discussed.
Whether to support Facebook Connect depends on your timeframe as well as your expected users. Facebook and FriendFeed are backing OAuth WRAP, so supporting Facebook Connect might not be necessary in the future.
The StackOverflow "featured" provider list isn't really relevant unless you care about what providers your users will use to authenticate. Otherwise, listing them is just a convenience for users. Frameworks such as JanRain's RPX might provide this UI for you.
除非您想与另一个使用特定登录机制的站点集成，否则我建议您自己编写。它对用户和您自己来说都很简单。诚然，您需要确保密码被安全存储，并且您应该使用 SSL 来发布登录信息，但这没什么大不了的。
如果今天要重新发明 Internet，我敢肯定会有一个通用 Internet 登录，它是 HTTP 标准的一部分并由 DNS 服务器处理（好吧，我不知道它是如何工作的 :)，但是不幸的是没有，我不认为 Open ID 是答案（也不是任何其他登录提供程序）。