HTTP基本身份验证应该用于客户端还是用户API身份验证？

保护RESTAPI的一个典型建议是通过SSL使用HTTP基本身份验证。我的问题是，HTTP基本身份验证应该只用于验证客户端（即访问API的应用程序），还是也可以用于验证用户（应用程序的消费者）

似乎大多数API都必须同时处理这两个问题，因为几乎所有web服务都使用某种用户帐户。只考虑推特或Vimeo有公共资源，还有私有（用户专用）资源。 一个简单的RESTAPI可以使用HTTP基本身份验证（通过SSL）同时进行客户端和用户身份验证，这似乎是合乎逻辑的

---

这是一个好的设计吗？

通过对客户端进行身份验证，您可能指的是API密钥的使用，此机制用于跟踪具体的应用程序/客户端。第二件事是，它允许您通过禁用密钥来禁用应用程序，例如，当客户端的作者从服务中删除他的帐户时。如果您想公开API，那么这是一个好主意

---

但是您需要记住，它没有提供真正的保护，每个人都可以下载客户端并提取该密钥。

我不建议使用基本身份验证进行API身份验证。当涉及到认证时，您应该考虑到应用程序（客户端）开发人员也必须实现认证的方方面面。其中的一部分不仅是身份验证本身，还包括如何获取凭据，甚至更多

我建议为最流行的编程语言使用客户端库附带的已建立的身份验证标准。这些库使开发人员更有可能调整您的API，因为它们减少了客户端的实现工作

使用身份验证标准的另一个重要原因是，它们使开发人员（和其他人）对身份验证系统的安全性更有信心。这些标准已由专家审核，其弱点和长处众所周知并有文件记录。除非您是安全专家，否则您不太可能开发一个几乎同样可靠的身份验证流：-）

该领域最为成熟的标准是，但您可以通过搜索“oauth备选方案”来找到备选方案

OAuth如何帮助您解决问题？

在OAuth 2中，应用程序客户端必须在访问任何受保护的资源之前为用户获取访问令牌。要获取访问令牌，应用程序必须使用其应用程序凭据对自身进行身份验证。根据使用情况（例如，第三方、移动设备），这是以OAuth标准定义的不同方式完成的

访问令牌不仅应表示用户，还应表示哪些操作可用于哪些资源（权限）。用户可以向不同的应用程序授予不同的权限，因此此信息必须以某种方式链接到令牌

然而，如何实现访问令牌的这种语义不是OAuth的一部分-它只是定义了如何获取访问令牌的流程。因此，访问令牌语义的实现通常是特定于应用程序的

创建访问令牌时，可以通过在后端存储访问令牌与其权限之间的链接来实现这种令牌语义。权限可以存储在每个用户-应用程序组合中，也可以仅存储在每个应用程序中，具体取决于您希望的细粒度

然后，每次API处理访问令牌时，您都会获取此信息，并检查用户是否有足够的权限访问资源和执行所需的操作

另一个选项是将权限信息放入访问令牌中，并对令牌进行签名或加密。当您收到访问令牌时，您将对其进行验证或解密，并使用存储在访问令牌中的权限来做出决定。你可能想看看如何做到这一点

后一种解决方案的好处是更好的可扩展性，并且在后端实现过程中减少了工作量。它的缺点是潜在的更大的请求（特别是使用RSA加密）和更少的令牌控制