我在决定如何为一个RESTful API实现身份验证时遇到了一些麻烦，该API既可供web应用程序使用，也可供移动应用程序使用。
首先，我想研究HTTPS上的HTTP基本身份验证作为一种选择。对于移动应用程序来说，用户名和密码可以安全地存储在操作系统钥匙链中，并且在传输过程中无法被拦截，因为请求是通过HTTPS发出的。对于API来说，它也很优雅，因为它将是完全无状态的。问题在于web应用程序。将无法访问这样的密钥链来存储用户名和密码，所以我需要使用cookie或localStorage，但我将用户的私人详细信息存储在一个容易访问的地方。
经过更多的研究，我发现了很多关于HMAC认证的谈论。我认为这种方法的问题是需要有一个只有客户端和服务器知道的共享秘密。除非我有一个API/Loginendpoint，它接受用户名/密码，并将秘密返回到cookie中存储，否则我如何将此每个用户的秘密传递给web应用程序中的特定用户？以便在以后的请求中使用。但是，这是在API中引入状态。
另外，我希望能够将API限制在某些应用程序中（或者，能够阻止某些应用程序使用API）。我看不出在web应用程序完全公开的情况下，这怎么可能实现。
我并不是真的想实现OAuth。对我的需求来说，这可能太过分了。
我觉得我可能还没有完全理解HMAC，所以我很欢迎一个解释，以及如何用web应用程序和移动应用程序安全地实现它。
我最终使用了HTTP Basic Auth，但是，不是每个请求都提供实际的用户名和密码，而是实现了一个endpoint来将用户名和密码交换为访问密钥，然后为每个经过身份验证的请求提供访问密钥。消除了在浏览器中存储用户名和密码的问题，但当然，如果您有权访问计算机并使用它，您仍然可以查找出令牌。事后看来，我可能会进一步研究OAuth，但它对初学者来说相当复杂。
您应该使用Oauth2。以下是如何实现的：
1）手机App
mobile app store客户端凭据（如您所述）。然后使用“资源所有者密码凭据授予”（参见http://tools.ietf.org/html/rfc6749#第4.3节）发送这些凭据。反过来，它获得一个（承载）令牌，它可以在以下请求中使用。
2）网站
网站使用“授权码授予”（见http://tools.ietf.org/html/rfc6749#第4.1节）：
>
网站看到未经授权的请求，并将浏览器重定向到REST API中启用HTML的autorization端点。
用户使用REST服务进行身份验证
REST站点将用户重定向回URL中带有访问令牌的网站。
网站调用REST站点，将访问令牌交换为授权令牌。
在这里，网站使用授权令牌访问REST服务（代表最终用户）-通常通过将该令牌作为“承载”令牌包含在HTTP授权头中。
这不是火箭科学，但它确实需要一些时间来完全理解。
3）限制某些应用程序的API访问
在OAuth2中，每个客户端都有一个客户端ID和客户端秘密（这里的“客户端”是您的移动应用程序或网站）。客户端必须在授权时发送这些凭据。您的REST服务可以使用它来验证调用客户端
我为自己的API解决了这个问题，非常容易和安全，而不需要公开任何客户端凭据。
我还把问题分成了两个部分。API身份验证-这是一个有效的请求从一个认可的实体（网站或本机应用程序）。API授权，是允许实体使用此特定端点和HTTP谓词。
授权使用访问控制列表和用户权限以及根据需要在API代码、配置和数据库中设置的设置编码到API中。API中的一个简单的if语句可以测试是否授权并返回适当的响应（未授权或处理API调用的结果）。
身份验证现在只是检查调用是否为正版。为此，我向客户端颁发自签名证书。只要他们愿意，就可以从他们的服务器上调用API--通常是在他们生成第一个页面时（或者在他们执行自己的应用程序登录检查时）。此调用使用我先前提供的证书。如果在我这边，我很高兴证书是有效的，我可以返回一个nonce和一个有时间限制的生成的API密钥。这个键在对其他API端点的所有后续调用中使用，例如在承载头中，它可以非常公开地存储在HTML表单字段、javascript变量或应用程序中的变量中。
nonce将防止重播攻击，如果有人想要，API密钥可能会被窃取--他们将无法在它过期后继续使用，或者如果nonce在他们进行下一次调用之前发生了更改。
每个API响应将包含下一个随机数，如果随机数不匹配，它将返回一个身份验证错误。事实上，这个随机数不匹配，我也杀了API键。然后，这将强制真正的API用户使用证书重新进行身份验证。
只要最终用户保持这些证书的安全，并且不公开他们用来进行初始身份验证调用的方法（比如让它成为一个可以重播的ajax请求），那么API就很好而且安全。
解决用户对API的身份验证问题的一种方法是在用户登录时从API请求一个身份验证令牌。然后可以将此令牌用于后续请求。您已经提到了这种方法--它很合理。
限制某些网络应用程序。您将希望每个web应用程序通过每个请求来标识自己，并在API实现中执行此身份验证。很直截了当。
