OAuth 对保护 REST API 有什么好处？答案

【问题标题】：What's the benefit of OAuth for securing REST APIs?OAuth 对保护 REST API 有什么好处？
【发布时间】：2013-11-28 06:44:38
【问题描述】：

我想制作一个 Web 应用程序，它是一个单页客户端，可与服务器中的 REST API 交互。我需要对我的应用程序的用户进行身份验证，而不是对第三方应用程序进行身份验证（后者是大多数传统 REST 参考书目的重点）。

在谷歌上搜索了很多之后，我发现有很多选项（基本 HTTP 身份验证、HTTP 摘要、OAuth 等），并且根据所选的一个可能会获得一些理想的属性。例如，基本身份验证很简单，但会发送未加密的普通密码，这不是一个好主意，除非您保证您的应用程序将在 TLS 下运行。相反，Digest 不会在每个请求上发送凭据，但会阻止强密码加密，并且容易受到中间人攻击[1]。 Meteor 引入 SRP，避免存储和发送密码[2]。

在我看来，共识是使用 OAuth，特别是 OAuth2 凭据流，因为我想授权访问我自己服务器上的资源[3][4][5]。我不明白这种特殊方法的好处是什么。我确实获得了使用 OAuth 作为委托身份验证形式的好处，就像使用 OpenID 进行联合身份验证一样：您根本不需要在服务器中处理身份验证数据。但是，如果您应用凭据流进行授权（或 OAuth1 2-legged 流），而不是引入第三方，看起来您仍然需要通过其他方式处理身份验证，例如 HTTP 基本或摘要。因此，如果您这样做，为什么不坚持唯一的方法，并在每个请求上发送凭据，而不是令牌？

这只是为了减少您必须实际发送凭据的请求数量？只是为了遵守 OAuth 约定？这些听起来不像是对其他方法的强烈争论。那么，我是遗漏了其他一些方面还是我误解了什么？

【问题讨论】：

标签： api security rest authentication oauth

【解决方案1】：

如果您没有进行联合，那么使用 OAuth 并不是一个很好的案例。

如果您只想对自己的服务进行身份验证，则基本或表单身份验证是可行的方法。正如您所指出的，问题在于您必须使用 HTTPS。但是，这适用于所有身份验证方法。

只要您使用 HTTPS，您就可以在传输过程中将凭据保护留给传输级安全性。这就是它的用途，并且（在大多数情况下）这就是它擅长的。如果您使用纯 HTTP（在您的应用程序中的任何位置，而不仅仅是用于身份验证），那么您就完成了。有各种非常聪明的中间人攻击，它们完全破坏了任何使用 HTTP 的任何系统的安全性（Moxie Marlinspike 在 2009 年的 Black Hat 上就该主题做了一个有趣的演示）。

【讨论】：

你有那个演示文稿的链接吗？
我认为基本的 HTTPS 不如基于令牌的身份验证，因为首先，您需要每次都发送密码，如果有人破坏 CA 签名密钥并开始签署新证书，这可能会成为问题与您的相匹配。（除非你做固定）。如果每次总是发送用户/p，带宽也是一个问题。我可能是错的，如果我错了，请说出来。
如果有人偷了你的 CA 的签名密钥，你就完蛋了。 Basic Auth 当然存在一些问题，这就是为什么我还提到了表单身份验证（在大多数情况下这可能是更好的解决方案）。我不喜欢大多数浏览器缓存基本身份验证凭据的方式，它们处理 UTF-8 密码的方式的差异是惊人的。这就是我提到表单身份验证的原因。除非您出于 API 原因需要支持基本身份验证，否则表单可能是更好的选择。