如何在使用OAuth2的资源所有者密码凭证授予类型

Question

时保持客户端凭据保密我们正在构建休息服务，并且我们希望使用OAuth 2进行授权。 current draft（5月19日的v2-16）描述了four grant types。它们是获得授权的机制或流程（访问令牌）。

1. 授权码
2. 隐格兰特
3. 资源所有者凭证
4. 客户端凭证

看来，我们需要支持他们四个，因为他们的目的不同。前两个（也可能是最后一个）可用于需要访问该API的第三方应用程序。授权代码是授权足以幸运地驻留在安全服务器上的Web应用程序的标准方式，而隐式授权流程则是客户端应用程序的选择，它不能完全保留其凭据的机密性（例如，移动/桌面应用程序，JavaScript客户端等）。
我们希望自己使用第三种机制，以在移动设备上提供更好的用户体验 - 而不是让用户访问Web浏览器中的登录对话框等，用户只需直接输入他或她的用户名和密码即可应用程序和登录。 我们还希望使用客户端凭证授予类型来获取可用于查看公共数据的访问令牌，而不与任何用户关联。在这种情况下，这不是什么授权，而是类似于API密钥的东西，我们只使用该密钥来访问已向我们注册的应用程序，如果需要，我们可以选择撤销访问。

所以我的问题是：

1. 你觉得我已经明白正确的不同类型的补助金的目的是什么？
2. 如何保持您的客户端凭据保密？在第三种情况和第四种情况下，我们都需要客户端上的客户端ID和客户端密码，这听起来不是一个好主意。
3. 即使您使用隐式授权类型并且不公开您的客户端密钥，是什么阻止另一个应用程序使用相同的授权机制和客户端ID来模拟您的应用程序？

总而言之，我们希望能够使用来自客户端应用程序的客户端凭证和资源所有者凭据流。这两种流程都需要您以某种方式存储客户端密钥，但客户端是移动设备或JavaScript应用程序，因此很容易被盗取。

Answer 1

我面临着类似的问题，而且对OAuth也相对陌生。我们在我们的API中实施了“资源所有者密码凭据”，以供我们的官方移动应用程序使用 - 网络流量看起来像在移动平台上使用会非常糟糕，并且一旦用户安装了应用程序并信任这是我们的官方应用程序，他们应该感觉舒适直接输入用户名/密码到应用程序。

问题是，正如你指出的，我的API服务器无法安全地验证应用程序的client_id。如果我在应用程序代码/包中包含client_secret，那么它会暴露给安装该应用程序的任何人，因此需要client_secret不会使该过程更安全。所以基本上，任何其他应用程序都可以通过复制client_id来模拟我的应用程序。

只是为了在每个点的直接回答：

1. 我不断重读规格的不同草案是否有任何的改变，我主要集中于资源所有者密码凭据部分，但我认为你对这些是正确的。客户端凭证（4）我认为也可以被内部或第三方服务使用，这些服务可能需要访问的不仅仅是“公共”信息，例如您可能有分析或需要跨所有用户获取信息的内容。

2. 我不认为你可以保留客户端上的任何保密信息。

3. 没有什么能阻止其他人使用您的客户端ID。这也是我的问题。一旦你的代码离开服务器，并作为一个应用程序安装或在浏览器中作为Javascript运行，你不能认为任何事情都是秘密的。

对于我们的网站，我们遇到了与您使用客户端证书流程描述的问题类似的问题。我最终做的是将认证移到服务器端。用户可以使用我们的Web应用程序进行身份验证，但是API的OAuth令牌存储在服务器端，并且与用户的Web会话相关联。 Javascript代码所做的所有API请求实际上都是对Web服务器的AJAX调用。因此，浏览器不是直接通过API进行身份验证，而是具有经过身份验证的Web会话。

看起来您的Client Credentials的用例不同，因为您在讨论第三方应用程序，并且只通过此方法提供公共数据。我认为你的担忧是有效的（任何人都可以窃取和使用任何其他人的API密钥），但是如果你只需要免费注册来获得API密钥，我就不明白为什么有人会真的想偷一个。

您可以监控/分析每个API密钥的使用情况，以尝试检测滥用情况，此时您可以使一个API密钥无效并为合法用户提供一个新密钥。这可能是最好的选择，但它绝对不安全。

如果你想锁定它更紧一点，你也可以使用Refresh Token-like方案，尽管我不知道你会获得多少收益。如果您每天一次过期使用Javascript暴露的api令牌，并要求第三方使用（秘密）刷新令牌进行某种服务器端刷新，那么被盗的api令牌永远不会超过一天。可能鼓励潜在的令牌盗贼只是注册。但对其他人来说，这是一种痛苦，所以不确定这是否值得。