我想创建一个Web应用程序，它是一个与服务器中的REST API交互的单页客户端。我需要验证我的应用程序的用户，而不是验证第三方应用程序（后者是大多数传统REST参考书目的焦点）。
经过Google搜索后，我发现有很多选项（基本HTTP身份验证，HTTP摘要，OAuth等）以及可能获得的几个理想属性，具体取决于所选择的属性。例如，Basic Auth很简单，但发送未加密的普通密码，除非您保证您的应用程序将在TLS下运行，否则这不是一个好主意。相反，摘要不会在每个请求上发送凭据，但会阻止强密码加密，并且在中间攻击[1]中容易受到攻击。 Meteor引入了SRP，避免了存储和发送密码[2]。
在我看来，共识是使用OAuth，特别是OAuth2凭据流，因为我想授权访问我自己的服务器[3] [4] [5]上的资源。我没有得到的是这种特殊方法的好处。我确实获得了使用OAuth作为委托身份验证形式的好处，就像使用OpenID进行联合身份验证一样：您根本不处理服务器中的身份验证数据。但是，如果您将凭据流应用于授权（或OAuth1 2-legged flow），而不是引入第三方，则看起来您仍然必须通过其他方式处理身份验证，例如HTTP基本或摘要。所以，如果你这样做，为什么不坚持这个唯一的方法，并在每个请求上发送凭据，而不是令牌？
这只是为了减少您必须实际发送凭据的请求数量？它只是坚持OAuth惯例？那些听起来不像其他方法的强烈争论。所以，我错过了其他一些方面，或者我误解了什么？
答案 0 :(得分：1)
如果您不是联盟，则使用OAuth的情况并不是很好。
如果您只想对自己的服务进行身份验证，则可以采用基本身份验证或表单身份验证。正如您所指出的，捕获的是您必须使用HTTPS。但是，这适用于所有身份验证方法。
只要您使用HTTPS，就可以在传输到传输级安全性时保留凭据。这就是它的用处和（大部分）它擅长的东西。如果您使用的是普通HTTP（应用程序中的任何位置，而不仅仅是身份验证），那么您就完成了。有各种非常聪明的MitM攻击完全打破了任何在任何地方使用HTTP的系统的安全性（Moxie Marlinspike在2009年的Black Hat上就这个主题做了一个有趣的演示）。