【发布时间】：2011-12-23 00:07:45
【问题描述】：
我有一个基本的疑问。 我遇到过许多开源 OAuth 库。但它们都依赖于它们所服务的社交网络。 我的问题是，如果所有 OAuth 库都依赖于网站，或者是否有任何真正通用的 OAuth 库。
谢谢
【问题讨论】：
标签： authentication oauth
【发布时间】：2011-12-23 00:07:45
【问题描述】：
TL;DR OAuth2 实现类似，但在某些细节上有所不同。如果一个库不是为特定的服务器实现而设计或测试的——很可能它根本无法使用它。我还没有看到支持多个提供者的库。
长篇大论： 虽然所有的 OAuth2 实现都是相似的，但细节是魔鬼。 例如，比较 Facebook 和 Google OAuth2 协议的第 1 步（请求代码）：
- 您使用 Facebook 注册并将整个域列入白名单，而对于 Google，您列出特定 URL。
- Facebook 允许您将任意 ¶ms 附加到 redirect_uri，Google 只允许传递 &state URL 参数
- Google 需要指定 response_type=code 参数，Facebook 不需要
获取访问令牌也不太兼容：
- Google 只允许 POST 请求，Facebook 支持 POST 和 GET
- Google 返回 JSON 响应，Facebook - URL 字符串
- Facebook 需要与步骤 1 中完全相同的 redirect_uri，Google 不会验证 &state 的存在
我并不打算将所有偏差的完整列表放在一起。 这只是我在阅读公共文档和试验 API 时注意到的一些示例。 VKontakte 主要使用 Facebook 的怪癖，但在第 2 步返回 JSON，类似于 Google。
在您完成所有挑战并获得访问令牌之后，事情变得更加困难。 OAuth 不会尝试涵盖 API 的结构或访问方式，因此您需要完全不同的例程来从每个网络获取用户名和电子邮件。
【讨论】：
-
感谢您的回复。在遇到这些问题后，我也提出了这个问题。 Fb 不需要对 URL 进行签名，但 OAuth 说它应该是（twitter 和linkedin 这样做）。我猜 Fb 和 google 已经偏离了很多。
-
我最近发现FB确实支持状态参数，所以使用它会“跨平台”。 JSON 使用的不一致可以通过检查响应的 MIME 类型来解决（Flask-OAuth 就是这样做的）。现在在我看来，大多数（全部？）实现都可以归结为单一的共同点。应该存在一个统治它们的 OAuth。然而，到目前为止，它是一种相当稀有的野兽。
我不确定您所说的依赖社交网络是什么意思。OAuth 是许多成熟的行业协议的标准化和综合智慧。它类似于当前使用的其他协议（Google AuthSub、AOL OpenAuth、Yahoo BBAuth、Upcoming API、Flickr API、Amazon Web Services API 等）。每个协议都提供了一种专有方法来交换用户凭据以获取访问令牌
每个社交服务提供商都实施了这些 OAuth 规范，无论是 Google/Yahoo/MSN/facebook。 唯一的区别在于每个服务提供商实现这些规范的方式。
简而言之，您还可以为您的应用程序提供 OAuth，您所需要做的就是实现这些规范并设置您的服务器以让您的应用程序的使用者使用它。
【讨论】：
-
我的意思是所有服务提供商的 OAuth 实现都一样吗？根据您的回答，我猜它会有所不同。另外我真正的意思是是否有任何适用于所有服务的 OAuth 库？我想这是不可能的，因为不同的服务可能有不同的实现
-
它们的实现方式可能不同，但在与消费者交互时，它们都有相同的请求和响应机制集
OAuth 1 是一个规范，提供者需要遵守规范或说明偏离规范的原因。
OAuth 2 还不是最终规范，只是一个草案，但我认为大多数提供商都很好地遵守了草案。
简而言之，一个好的 OAuth 1 库可以与任何实施良好的提供者一起使用。我对 OAuth 2 的经验较少，但我相当确定那里的库标准化程度较低。
【讨论】：