保护 REST API 的典型建议是使用基于 SSL 的 HTTP 基本身份验证。我的问题是，HTTP Basic Authentication 应该只用于验证客户端（即访问 API 的应用程序），还是也可以用于验证用户（应用程序的消费者）？
似乎大多数 API 都必须同时处理这两种情况，因为几乎所有 Web 服务都使用某种用户帐户。只需考虑 Twitter 或 Vimeo — 有公共资源，也有私有（特定于用户的）资源。
一个简单的 REST API 可以使用 HTTP 基本身份验证（通过 SSL）同时进行客户端和用户身份验证，这似乎是合乎逻辑的。
这是一个好的设计吗？
我不建议使用基本身份验证进行 API 身份验证。当涉及到身份验证时，您应该考虑应用程序（客户端）开发人员也必须实现其身份验证方面。其中一部分不仅是身份验证本身，还包括如何获取凭据，甚至更多。
我建议使用已建立的身份验证标准，该标准随最流行的编程语言的客户端库一起提供。这些库使开发人员更有可能调整您的 API，因为它们减少了客户端的实现工作。
使用身份验证标准的另一个重要原因是它们使开发人员（和其他人）对您的身份验证系统的安全性更有信心。这些标准已经过专家审核，它们的弱点和优势是众所周知的并记录在案。除非您是安全专家，否则您不太可能开发出几乎一样可靠的身份验证流程 :-)。
该领域最成熟的标准是OAuth，但您可以通过搜索“oauth Alternatives”找到替代品。
OAuth 如何帮助您解决问题？
在 OAuth 2 中，应用程序客户端必须在访问任何受保护的资源之前为用户获取访问令牌。要获取访问令牌，应用程序必须使用其应用程序凭据对自己进行身份验证。根据用例（例如，第 3 方、移动设备），这可以通过 OAuth 标准定义的不同方式完成。
访问令牌不仅应该代表用户，还应该代表哪些操作可以用于哪些资源（权限）。用户可以向不同的应用程序授予不同的权限，因此必须以某种方式将这些信息链接到令牌。
然而，如何为访问令牌实现这种语义并不是 OAuth 的一部分——它只是定义了如何获取访问令牌的流程。因此，访问令牌语义的实现通常是特定于应用程序的。
创建访问令牌时，您可以通过在后端存储访问令牌及其权限之间的链接来实现此类令牌语义。可以为每个用户-应用程序组合存储权限，也可以为每个应用程序存储权限，具体取决于您希望事情的精细程度。
然后，每次 API 处理访问令牌时，您都会获取此信息并检查用户是否有足够的权限来访问资源并执行所需的操作。
另一种选择是将权限信息放入访问令牌中并对令牌进行签名或加密。当您收到访问令牌时，您将对其进行验证或解密，并使用存储在访问令牌中的权限做出决定。您可能想看看Json Web Tokens (JWT)如何实现这一点。
后一种解决方案的好处是在后端实现过程中具有更好的可扩展性和更少的工作量。它的缺点是可能更大的请求（尤其是使用 RSA 加密）和对令牌的控制较少。
通过对客户端进行身份验证，您可能意味着 API 密钥的使用，此机制用于跟踪具体的应用程序/客户端。第二件事是，它使您可以通过禁用密钥来禁用应用程序，例如当客户的作者从服务中删除他的帐户时。如果您想公开您的 API，那么这是一个好主意。
但是您需要记住，它没有给您真正的保护，每个人都可以下载客户端并提取该密钥。