使用OAuth密码凭证授予优惠令牌访问身份验证

Question

我正在为使用Rails 5的移动应用程序创建一个API。目前，我不需要三脚授权，因为API只会被我们自己的移动应用。

我想选择这两个选项之一：

1. 守门人+设计：我可以使用看门实施的OAuth 2.0，但我将只使用密码凭据格兰特，至少现在。
2. Rails自己的ActionController::HttpAuthentication::Token模块+设计：这似乎是更简单的方法。

老实说，我看不出Token Access Authentication方法和OAuth 2.0's Password Credentials Grant之间的区别。

如何选择一个而不是另一个？是否还有其他选择需要考虑？

Answer 1

两个在概念上是不同的东西：

• “令牌访问身份验证”指定描述（可能是长期）令牌应该如何提交给服务器安全的协议。它没有说明令牌的来源或应该如何解释。
• “密码凭据授予”是完整的OAuth流程的一部分，描述了获取（通常是短暂的）令牌的手段。

从某种意义上说，您可以使用Password Credentials Grant来使用OAuth获取令牌，然后在Token授权标头中使用此令牌获取访问权限。

然后问题就变成了：当我们可以使用存储在应用程序中的（永久和秘密）令牌来为（临时）令牌交换（永久和秘密）凭证的额外往返时，无论如何，授权立即。

正如我所看到的，使用完整的OAuth流程有两个潜在的好处。首先，它允许您自然地为第三方添加其他授权方式。其次，它可以让您随时撤销令牌，并使用其他方式强制重新授权（当然，如果您实施这些方式），而不必发明任何车轮。

另一方面，您可以随时在需要时添加任何其他“令牌生成”部件。因此，如果您目前的计划是在代码中对代码凭证进行硬编码，那么我会怀疑您最好依靠Token授权。如果攻击者嗅探一个Bearer令牌，他们（通常）会（通常）获得对服务器的完全令牌访问权限，直到它到期为止。如果攻击者嗅探到Bearer令牌， 。 Token令牌（通常）不是这种情况。当然，如果攻击者无论如何都可以从您的应用中提取共享密钥，那么这一切都不是非常重要。

Answer 2

如果您所拥有的只是“单一目的API”（仅适用于移动应用程序），则在安全性方面没有太大差异。

但是，如果您希望扩展此API以供外部服务使用，那么使用Doorkeeper实现OAuth 2.0时您将处于更好的位置，因为您可以轻松配置，例如授权代码授予他们。 所以，我会说“门卫+设计”选项更具前瞻性，因为它提供了更多的选项，而HTTP Token authentication实现起来要简单得多。