OAuth 1.0 - 如何同时实现 2-legged 和 3-legged 身份验证？

Question

我已经实现了一个 OAuth 1.0a 提供程序，并且拥有可以使用标准 3-legged 身份验证成功对其进行身份验证的 OAuth 客户端。

OAuth 保护我服务器上的 REST API，而我有一个移动应用正在使用它。

在我的移动应用程序中，我有一些功能（端点），甚至在最终用户登录其私人帐户之前就可以访问这些功能。
有些用户甚至可能只想使用公共功能而不创建帐户。

我想使用 OAuth 保护“公共”和“用户专用”端点。

因此我认为要走的路是按照以下方式使用OAuth（但我可能错了……非常错误）。

移动应用程序在首次启动时会首先进行 2-legged 身份验证。这样，移动应用程序将获得“2-legged”令牌。移动应用将使用此令牌访问公共端点。

当（如果）用户请求登录应用程序时，移动应用程序将执行 3-legged 身份验证并获得“3-legged token”。从现在开始，应用程序将忘记之前的 2-legged 令牌并使用 3-legged 令牌 访问公共和私有端点。

1) 第一个问题。那有意义吗？还有其他好方法吗？

现在我的问题是：我（服务器提供商）如何知道移动应用程序是否要使用 2-legged 进行身份验证？我想，作为提供者，我需要知道这一点才能决定是否将客户端重定向到登录 供用户填写的表格（在 3 腿的情况下），或者我将发出一个已经授权的请求令牌（在 2 腿的情况下），以便可以交换访问令牌（至于 3腿）。

我这样做的想法是为客户提供 2 个使用者密钥：一个在他们想要 2-legged 时使用，一个在他们想要 3-legged 时使用。我，作为提供者，我会根据收到的消费者密钥知道要提供哪个流程。

2) 第二个（也是最后一个问题）。这是明智的吗？有没有更好的实现方式？

我看到人们通过只允许客户端（消费者）发送一个空的访问令牌来实现 2-legged。是这样吗？

谢谢。

Answer 1

OAuth 旨在管理第三方应用程序对您的 REST API 的访问。 例如。其他一些公司开发了一个将使用您的 API 的应用程序。而且您不希望您的客户向第三方提供这些服务的密码。在这种情况下，OAuth 是解决方案。如果没有第三方应用程序，则不需要 OAuth。

如果您有单一服务并且只有您的应用程序在使用它，那么您不需要实施任何 OAuth。您需要创建通常的用户/密码登录（并且可能正确检查）机制。

使用 HTTPS 足以保护端点交互。如果您想保护移动应用或其他一些 REST 消费者上的商店内容，则必须在保存之前对其进行加密。

更新： 如果您想保护“端点”，那么 3-legged OAuth 就是解决方案。 2-legged 解决方案需要将第三方应用程序 + 您的 OAuth 应用程序（或 lib）安装到用户设备。否则用户可能会被类似的 UI 伪造，而只是提供一些第三方用户和密码。

• 2- and 3- legged OAuth comparison
• 如果您的 REST API 服务是基于 java 的，最好的解决方案是twitter OAuth library。
• 最好的 java OAuth 消费者库（我发现并使用）是Scribe