我目前处于创建在后端使用REST API的Web应用程序（HTML5，JS等）的早期阶段（Java，特别是Jersey v1.18）。将要存储的数据的性质非常敏感，因此安全性是我开始关注的，即使应用程序仅处于早期阶段。最终的目标是拥有本机移动应用程序，并可能通过相同的API为外部客户端提供数据访问。
在我的研究中，我已经确定了各种身份验证方法，包括HTTP Basic，基于令牌，会话cookie，OAuth，HMAC等。这里的关键组件是REST API将主要由用户访问而不是其他应用程序或后端。因此，具有“登录/注销”等效项非常重要，这归结为用户级认证。
到目前为止，HMAC身份验证看起来最有希望，因为我们目前还没有计划与任何OAuth提供商集成。
我已经阅读了数十篇SO帖子以及以下文章： http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ http://www.errant.me.uk/blog/2013/04/authenticating-restful-web-applications/（注意：这显然很糟糕，因为不建议使用用户名进行腌制）
理想情况下，HMAC似乎是要走的路，但我还没有看到处理共享秘密的推荐方法。使用资源验证凭据然后提供与HMAC方案一起使用的令牌/随机数的想法似乎是一种选择，但我质疑仅仅使用此令牌/随机数作为令牌的优势。
我知道已经详细讨论了REST API的HMAC身份验证，但是当与用户期望的身份验证详细信息（用户名，电子邮件，密码等）结合使用时，是否有任何推荐的方法不需要预共享密钥？
答案 0 :(得分：1)
这主要是基于意见的问题，但我会提供两分钱：只需要一个会话cookie。
如果您的主要受众是人类，并且您不需要与第三方集成，请不要为OAuth烦恼。只需确保您的API仅通过HTTPS提供，并发出服务器可以在登录后撤消的会话令牌。严格来说，它不需要是一个cookie;我已经看到过将HTML存储在HTML5会话存储中并将其提供给Authorization标头或作为查询参数的API。
如果您正确设置了SSL，您的用户将在浏览器中获得预期的挂锁，并且您和客户之间的任何人都可以安全。如果客户遭到入侵，您仍然会被搞砸。由于客户不能保守秘密，因此对于更复杂的HMAC方案没有太多优势。