对于公共REST来说，OAuth2 ROPC与Basic？

Question

这里我感兴趣的具体用例是根据公共可用的服务器端点(例如公共REST )验证REST客户端。

这里最简单的解决办法是基本的八月。但是我经常听到OAuth2在几乎所有的情况下都被吹捧为一个优越的解决方案。

问题是，对REST服务器进行身份验证的REST客户端唯一可行的OAuth2授予类型是资源所有者密码凭据(ROPC)，因为Code和隐式Grants要求用户登录并手动授权客户端应用程序(由authorize托管)一个UI/网页。

ROPC的工作方式是发送资源所有者的用户名/密码，并将客户机ID作为查询字符串params?!？这甚至更不安全(IMHO)，然后是Basic Auth，它至少对凭证进行编码，并将它们发送到一个可以被TLS加密的头中！

所以我问:在公共REST环境中，OAuth2 ROPC真的比基本的八月好吗？什么比OAuth2 ROPC更安全？

更新

我刚刚读到了这篇优秀的文章，它解释了亚马逊的基于非OAuth2的AWS REST安全性。它本质上是一种基于私钥的解决方案，其中生成每个REST请求的散列，并将其作为sidecars沿正常(未加密)请求发送。只有客户端和服务器知道私钥，所以当服务器接收到请求(再次包含普通请求+散列请求)时，服务器查找客户端的私钥，对正常请求应用相同的散列，然后比较这两个散列。

这听起来更复杂，复杂和安全比OAuth2's ROPC！除非我在这里遗漏了一些重要的东西，否则OAuth2 ROPC只是发送client_id、username和password作为查询字符串params...totally，并且完全不安全！这种基于HMAC/散列的解决方案似乎更令人印象深刻和安全。

问题是，即使是这篇文章的作者也继续说：

您还可以慢慢地意识到并接受在某个时候您必须实现将要 .

巴巴什么？！！如果OAuth2不如这个聪明的基于HMAC/散列的解决方案安全，那么为什么本文的作者认为OAuth需要在某个时候被接受。我太困惑了。

Answer 1

我相信您被错误地告知了URL中GET变量的加密

唯一能够在请求中查看GET变量的人是原始计算机和接收服务器(链接)。

只有基于发送HTTPS请求的域的DNS查找是不加密的。其他所有东西，端口、GET变量、资源ID都是加密的。

唯一要注意的是，接收服务器可能会注销完整的请求路径，但是您可以控制它，这样您就可以在您认为合适的时候保护该数据。

Answer 2

基本身份验证不是保护REST的好方法。我解释了为什么在这个答案中。

当您构建REST时，您正在用资源服务器术语实现OAuth2。您的API所需要做的就是验证与授权HTTP报头中的请求一起传递的令牌是否有效，并且来自可信的发行者。如果没有可用的库，请参见此链接获得如何实现验证的步骤。

您来自授权服务器的客户端获取令牌。如何取决于它是什么客户类型。请记住，在向授权服务器注册客户端时，需要指定要使用的客户端类型。

如果web应用程序与您的服务器通信，它可以使用授权代码授予。如果它是一个不受信任的客户端，比如移动应用程序或JavaScript应用程序，那么它应该使用隐性赠与。

对于不能与资源所有者交互的后端服务，可以使用客户凭据授予。对于命令行工具，可以使用客户端凭据或资源所有者密码授予。

这完全取决于您使用的是哪种客户端。

最后，验证JWT令牌发生在资源服务器上，而不需要与授权服务器对话。这将导致一个更好的可伸缩体系结构，然后是需要为每个客户端查找私有数据的解决方案。

Answer 3

要么安全要么不安全。不多也不差。拥有base64并不能使基本的Auth (或任何事情)更加安全。

如果使用像Https这样的加密管道，发送未加密的内容没有什么错。

OAuth有更多的特性，如果需要的话可以使用它。对于其他任何事情，例如银行业务，使用基本的挑战-反应是安全的。