Appengine 上的社交身份验证有哪些不同选项 - 它们如何比较？

Question

[这个问题旨在作为捕获我的发现并对其进行健全性检查的一种手段 - 我将把我的答案放在套件中，看看会出现什么其他答案和评论。]

我花了一点时间尝试让我了解 (python) Appengine 的不同社交身份验证选项。我对 Google 提供的身份验证机制如何与其他社交身份验证机制交互感到特别困惑。由于 Google 与第三方 OpenID 提供商有很好的集成，但一些最大的社交网络不是 OpenID 提供商（例如 facebook、twitter），这一事实使情况变得复杂。 [请注意，facebook 可以使用 OpenID 作为中继方，但不能作为提供者]。

接下来的问题是：Appengine 中的社交身份验证有哪些不同选项，每种选项有何优缺点？

Answer 1

在我对这个问题的研究中，我发现基本上有以下三种选择：

1. 使用 Google 的身份验证机制（包括通过 OpenID 联合登录）

   • 优点：
     • 您可以通过 Appengine 提供的用户服务轻松查看谁登录了
     • Google 负责安全保障，因此您可以确信它经过了充分测试
   • 缺点：
     • 这只能与第三方 OpenID 提供商集成；目前无法与 facebook/twitter 集成

2. 使用已知框架（例如tipfy或django）提供的社交认证机制

   • 优点：
     • 这些可以与所有主要的社交认证服务集成
     • 它们的使用相当广泛，因此它们可能非常强大并且经过了良好的测试
   • 缺点：
     • 虽然它们可能经过了充分测试，但可能无法维护
     • 它们确实是一个更大框架的一部分，您在部署应用之前可能必须熟悉该框架

3. 进行自己的社交身份验证

   • 优点：
     • 您可以混合任何您喜欢的 OpenID 和 OAuth 风格
   • 缺点：
     • 您最有可能引入安全漏洞
     • 除非您有一些使用这些技术的经验，否则这可能是最耗时的

进一步说明：

• 很可能每个人最终都会转向 OpenID，然后是标准谷歌身份验证应该在任何地方都有效
• 第一个选项允许您在谷歌的身份验证出现问题时指责谷歌；第二个选项给您带来了更多的责任，但仍然允许您在出现问题时说您使用了广泛使用的解决方案，而最后一个选项将所有责任归于您
• 大多数问题都围绕会话管理 - 在情况 1 中， Google 负责所有的会话管理，并且对开发人员来说几乎是不可见的；在第 2 种情况下，会话管理由框架处理，在第 3 种情况下，您必须设计自己的会话管理。