我目前处于创建Web应用程序（HTML5，JS等）的早期阶段，该Web应用程序在后端（Java，特别是Jersey v1.18）上使用REST API。 将要存储的数据的性质非常敏感，因此即使应用程序还处于早期阶段，安全性也是我开始关注的问题。 最终目标将是拥有本机移动应用程序，并可能通过相同的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身份验证进行了详细讨论，但是当与用户期望的身份验证详细信息（用户名，电子邮件，密码等）结合使用时，是否有任何建议的方法不可行需要预共享的密钥？
这主要是一个基于意见的问题，但是我要提供两美分：只需购买会话cookie。
如果您的主要受众是人类，并且您不需要与第三方集成，请不必担心OAuth。 只需确保您的API仅可通过HTTPS使用，然后发出会话令牌即可让服务器在登录后撤消该令牌。 严格来说，它不必是cookie。 我已经看到了将令牌存储在HTML5会话存储中并提供给Authorization标头或作为查询参数的API。
如果您正确设置了SSL，您的用户将在浏览器中获得预期的挂锁，并且您和客户端之间的任何人都将免受任何伤害。 如果客户受到损害，无论如何您都会被搞砸。 而且由于客户端无法保密，因此更复杂的HMAC方案没有太多优势。