Facebook 连接还是 OpenID？从开发者的角度

Question

我最近接到一份合同，负责开发一个需要 Facebook-Connect 作为其身份验证机制之一的应用程序。

在我的 Facebook-Connect 解决方案上工作时，我意识到它正在实施单点登录身份验证方案，如果您登录到一个网站，您就会登录到所有网站。就个人而言，我不喜欢这种方法，并且发现在尝试通过您（开发人员）可以控制的单个进程来汇集所有身份验证系统时很难（并非不可能）使用。我也认为它引入了不必要的security issues (see Risks of Internet Deployment) 只是为了稍微改善用户体验。

在研究使用该技术的策略时，我注意到博客圈几乎将 Facebook-Connect 奉为身份验证的圣杯，相互呼应，并强烈要求“OpenID 太复杂”。同时，我还没有真正看到很多著名的开发人员和安全专家就此事举旗或发表意见。我对 OpenID 的唯一经验是使用 StackOverflow 和相关网站。一开始我也很难理解它是什么，但当我意识到我可以使用我的 google 凭据登录时，体验非常顺利。

我是偏执狂还是错过了每个人都拥有的东西？ Facebook-Connect 真的是 OpenID 更好的替代品，还是每个人都在喝别人的 Kool Aid？

---

编辑：

在解决这个问题后，我确认 facebook-connect 登录方案不太理想。整个 iframe/js/cookie/reload 很丑，很容易出问题。将 fb 登录集成到现有的身份验证系统本身就是一个练习。你将不得不做出一些妥协。我必须写另一篇文章来解释我是如何做到的。

在我看来，Facebook 确实有点痴迷于单点登录。大多数人都不知道 facebook 为他们自己的网站启用了 OpenID，但即使他们实现它的方式也是模拟 SSO 并使其有点毫无意义。我认为 OpenID 应该工作的方式：你去一个新网站，如果你有一个 OpenId 帐户，输入 url，登录到你的提供商，然后你就可以了。然后你可以继续完成其他信息。

Facebook 不会预先为您提供 OpenID 登录。相反，您首先必须注册并登录，然后转到帐户设置并在关联帐户下选择一个 OpenID 提供商。但是，与理解这一点的 StackOverflow 不同，Facebook 只允许您使用自己的 OpenID 登录，前提是您指示您的提供商记住该设置。为什么？它使它更像 SSO。如果您不选中要求记住的 google 框，OpenID 将无法在 facebook 上运行。

撇开登录不谈，facebook-connect 可以正常工作，但仍有许多难点。有几件事让我抓狂并诅咒那个 api：

• facebook 文档分散且没有适当精简。在打开它的第一个小时内，您将在浏览器中打开至少 10 个标签。如果/当您偶然发现您认为将来可能有用的有趣主题时，请确保正确地为它们添加书签，不要依赖导航再次找到它们，因为有时关键文章被埋得很深。我知道最近记录 api 的 wiki 方法使很多项目变得懒惰，但常见的是，这是 facebook。他们应该有办法聘请团队来提供适当的用户指南。因此，请记住在开始之前为自己准备一个漂亮的 Facebook 书签文件夹。
• api中有很多方法，祝你找到一个如何使用它们的例子，你必须依靠直觉。
• 很多时候，当某些事情不能如您所愿时，没人知道为什么。在访问论坛页面时，以假设和谣言的形式给出解释。例如登录时，为什么有些应用程序有一个弹出登录窗口，而有些应用程序有一个 js 模态对话框？是否有可能控制这种行为？没有人确定。有传言称 Facebook 正在进行一些测试，但不让任何人知道。
• 并非一切都像宣传的那样工作。也就是说，您可能会发现自己被鼓励使用某个功能，浪费了宝贵的时间来学习、实施、调试它，然后当您将它放在 try/catch 异常处理程序中时才发现它不适用于 facebook-connect。例如feed.publishUserAction。
• facebook 试图变得用户友好。他们浪费了宝贵的资源来推动只在一半时间内工作的自动化 API（xfbml），而不是鼓励开发人员通过使用已被证明在大多数时间工作的更基本的东西（伪 sql + html）来利用他们来之不易的知识。例如我浪费时间尝试使用 ajax/xfbml/js 的组合从他们的服务器中提取朋友的图片。它适用于几个请求，然后完全停止工作。然后我决定使用他们的 facebook 查询语言 (fql) 直接从他们的数据库中提取数据，并在 html 中创建我自己的标记。工作100％。如果你是一个真正的开发者，我给你的建议是，不要相信 facebook 试图满足所有人的“一切都很简单”的口头禅，事实并非如此。除了熟悉您的编程平台的 facebook 客户端 api（PHP、Python、Java 等）之外，还可以投资学习使用fql 可以直接从他们的服务器中提取什么，以及使用JS Client API 在浏览器上可以做什么（不要与 fbjs 混淆）。您很可能会发现后两个是您完成大多数事情所需的全部内容。

我确定列表并没有到此结束，但从我的脑海中就到了。

Answer 1

警告：以下是强烈的意见。

是的，他们正在喝 Kool-Aid。 Facebook Connect 是专有的、依赖于提供商的单点登录以及更多功能。 Facebook 倒闭了，或者被认为不值得信任，然后你就完蛋了。

OpenID 绕过了这一点。它目前存在主要的用户体验问题，但从长远来看，它是一个更好的解决方案，因为它使系统摆脱了对单个提供商的依赖（并过滤所有流量）。此外，它的规范和实现看起来更清晰——这些 JavaScript/IFrame 东西都没有。只是普通的 HTTP 请求和重定向。这也为您提供了更好的浏览器兼容性。

Facebook Connect 修复了用户体验问题，但代价是浏览器支持和提供商选择。这是一个短期务实的胜利，但我认为从长远来看这不是一个好主意。

Answer 2

单点登录方案现在在主要应用中相当普遍。如果您登录 Gmail，则您已登录 Google 的所有产品。我认为这在某种程度上是有道理的，特别是如果应用程序是相互连接的，是一项主要服务，并且提供商有最好的安全人员在幕后工作。

现在对于 OpenID，我认为这也是一个好主意，但 OpenID 仍然不是很容易访问。它本应彻底改变中小型网站的登录方式，但事实并非如此。有很多网站在使用它，但显然还不够。大多数网站仍然使用自己的登录方案，称之为昏昏欲睡或对单独的提供商感到不安。

但我认为像 OpenID 这样的东西迟早会出现，但要使其发挥作用，需要大力推动。像谷歌这样的人。

想象一下，如果您能够使用您的 google ID 登录 SO。

现在我认为你不必对 Facebook-Connect 感到不舒服，但我推荐 OpenID，即使我自己还没有使用它 :)（嗜睡）

Answer 3

你看过Google Friend Connect吗？它类似于 Facebook Connect，但它是基于 Open ID 的，因此并非完全为 Google 专有。它似乎也解决了 Open ID 用户体验问题。

rpxnow.com 在解决 Open ID 用户体验问题方面也做得很好。