Appengine的社会认证有哪些不同的选择 - 他们如何比较？

Question

[这个问题的目的是捕捉我的发现和理智检查它们 - 我会提出我的答案toute套件,看看其他答案和评论出现.]

我花了一点时间试图了解(python)Appengine的不同社交认证选项.我对Google提供的身份验证机制如何与其他社交身份验证机制进行交互感到特别困惑.由于谷歌与第三方OpenID提供商的良好整合,但一些最大的社交网络不是OpenID提供商(例如facebook,twitter),因此情况变得复杂.[请注意,Facebook可以使用OpenID作为中继方,但不能作为提供商使用].

接下来的问题是:在Appengine中社交认证的不同选择是什么？每种选择的优缺点是什么？

Answer 1

在我对这个问题的研究中,我发现基本上有三种选择:

1. 使用Google的身份验证机制(包括通过OpenID进行的联合登录)

   • 优点:
     • 您可以通过Appengine提供的用户服务轻松查看登录的用户
     • 谷歌处理安全性,因此您可以确定它经过了充分的测试
   • 缺点:
     • 这只能与第三方OpenID提供商集成; 它目前无法与facebook/twitter集成

2. 使用已知框架(如tipfy或django)提供的社交身份验证机制

   • 优点:
     • 这些可以与所有主要的社会认证服务集成
     • 它们被广泛使用,因此它们可能非常强大且经过良好测试
   • 缺点:
     • 虽然它们可能经过了很好的测试,但它们可能无法维护
     • 它们确实是一个更大的框架的一部分,在部署应用程序之前,您可能必须对此感到满意

3. 滚动您自己的社交认证

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

附加说明:

• 很可能每个人最终都会迁移到OpenID,然后标准的Google身份验证应该可以在任何地方使用
• 如果他们的身份验证存在问题,第一个选项允许您指向Google; 第二个选项对您施加更多责任,但仍允许您说如果出现问题则使用广泛使用的解决方案并且最终选项将所有责任都归咎于您
• 大多数问题都围绕着会话管理 - 在案例1中,Google完成了所有的会话管理,而且开发人员看不到它; 在案例2中,会话管理由框架处理,在第三种情况下,您需要设计自己的.