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