API 身份验证和授权
在用户使用您的 API 发出请求之前，他们通常需要注册 API 密钥或了解对请求进行身份验证的其他方法。API 在对用户进行身份验证的方式上有所不同。某些 API 要求您在请求标头中包含 API 密钥，而其他 API 则需要精心设计的安全性，因为需要保护敏感数据、证明身份并确保请求不被篡改。在本节中，您将了解有关身份验证和授权的更多信息，以及文档中应关注的内容。
定义术语
首先，让我们定义一些关键术语：
- 身份验证：指证明正确的身份
- 授权：指允许某个操作
API 可能会对您进行身份验证，但不会授权您发出特定请求。
身份验证和授权
如果 API 缺乏安全性的后果
为什么 API 甚至需要身份验证？对于只读 API，有时用户不需要密钥。但大多数商业API确实需要API密钥或其他方法形式的授权。如果您的 API 没有任何安全性，则用户无需任何注册即可进行无限量的 API 调用。允许不受限制的请求会使 API 的收入模式变得困难。
此外，如果没有身份验证，就没有一种简单的方法将请求与特定的用户数据相关联。而且没有办法防止恶意用户的请求，这些请求可能会删除其他用户的数据（例如，通过对另一个帐户发出 DELETE 请求）。
最后，您无法跟踪谁在使用您的 API，或者哪些终端节点使用最多。显然，API 开发人员必须考虑如何对向其 API 发出的请求进行身份验证和授权。
总体而言，使用 API 进行身份验证和授权具有以下用途：
- 仅对注册用户对 API 的调用进行身份验证
- 跟踪谁在发出请求
- 跟踪 API 的使用情况
- 阻止或限制任何超过速率限制的请求者
- 对不同的用户应用不同的权限级别
不同类型的授权
有几种方法可以进行授权。以下是您可能遇到的各种类型的 API 授权：
接口密钥
大多数 API 要求您注册 API 密钥才能使用该 API。API 密钥是一个长字符串，通常包含在请求 URL 或请求标头中。API 密钥主要用作识别进行 API 调用的人员（验证您是否使用 API）的一种方式。API 密钥还可能与你注册的特定应用相关联。
APK 密钥使用标头属性中的字符串来授权请求
API 可能会同时为您提供公钥和私钥。公钥通常包含在请求中，而私钥更像是密码，仅用于服务器到服务器的通信。对于某些 API 文档站点，当你登录到站点时，你的 API 密钥会自动填充到示例代码和 API 资源管理器中。
基本身份验证
另一种类型的授权称为基本身份验证。使用此方法，发送方将 放入请求标头中。用户名和密码使用Base64进行编码，这是一种编码技术，可将用户名和密码转换为一组64个字符，以确保安全传输。下面是请求标头中的基本身份验证示例：username:password
Authorization: Basic bG9sOnNlY3VyZQ==
使用基本身份验证的 API 也将使用 HTTPS，这意味着消息内容将在 HTTP 传输协议中加密。（如果没有HTTPS，人们很容易解码用户名和密码。
当 API 服务器收到消息时，它会解密消息并检查标头。解码字符串并分析用户名和密码后，它会决定是接受还是拒绝请求。
在 Postman 中，可以通过单击“授权”选项卡，从下拉选择器中选择“基本身份验证”，然后在每行冒号右侧键入用户名和密码来配置基本授权。“标头”选项卡将显示如下所示的键值对：
Authorization: Basic RnJlZDpteXBhc3N3b3Jk
当您输入用户名和密码并选中“基本身份验证”时，Postman 会自动为您处理 Base64 编码。
HMAC（基于哈希的消息授权代码）
HMAC代表基于哈希的消息授权代码，是一种更强的身份验证类型，在金融API中更常见。使用HMAC，发送方和接收方都知道其他人没有的密钥。发送方根据某些系统属性（例如，请求时间戳加帐户 ID）创建消息。
然后，消息由密钥编码，并通过安全哈希算法 （SHA） 传递。（哈希是基于算法的字符串的加扰。生成的值（称为签名）放置在请求标头中。
当接收方（API 服务器）收到请求时，它会采用相同的系统属性（请求时间戳加帐户 ID），并使用密钥（只有请求者和 API 服务器知道）和 SHA 来生成相同的字符串。如果字符串与请求标头中的签名匹配，则接受请求。如果字符串不匹配，则请求将被拒绝。
下图显示了此工作流：
工作流程
重要的一点是，密钥（对重建哈希至关重要）只有发送方和接收方知道。密钥不包含在请求中。当您希望确保请求既真实又未被篡改时，将使用 HMAC 安全性。
奥傲 2.0
对用户进行身份验证和授权的一种常用方法是 OAuth 2.0。此方法依赖于身份验证服务器与 API 服务器通信以授予访问权限。当您使用网站时，您经常会看到 OAuth 2.0，系统会提示您使用推特、谷歌或脸书等服务登录。
登录窗口
OAuth有几个变种 - 即“单腿OAuth”和“三条腿OAuth”。当您没有敏感数据需要保护时，将使用单腿 OAuth。如果您只是检索一般的只读信息，则可能会出现这种情况。
相比之下，当您需要保护敏感数据时，将使用三条腿的 OAuth。在此方案中，有三个组正在交互：
- 身份验证服务器
- 资源服务器（API 服务器）
- 用户或应用
以下是 OAuth 2.0 的基本工作流程：
OAuth 身份验证
首先，使用者应用程序将应用程序密钥和机密发送到身份验证服务器上的登录页。如果经过身份验证，身份验证服务器将使用访问令牌响应用户。
访问令牌打包到响应重定向 （302） 到请求的查询参数中。重定向将用户的请求指向资源服务器（API 服务器）。
然后，用户向资源服务器（API 服务器）发出请求。访问令牌将添加到 API 请求的标头中，后跟令牌字符串。API 服务器检查用户请求中的访问令牌，并决定是否对用户进行身份验证。Bearer
访问令牌不仅为请求者提供身份验证，还定义了用户如何使用 API 的权限。此外，访问令牌通常会在一段时间后过期，并要求用户重新登录。有关 OAuth 2.0 的详细信息，请参阅以下资源：
- 学习API技术写作2：作家的REST（乌德米），彼得·格伦鲍姆
- 奥奥特简化，由亚伦·帕雷茨基
使用身份验证记录的内容
在 API 文档中，您无需向外部用户详细解释身份验证的工作原理。实际上，不解释身份验证过程的内部详细信息可能是最佳实践，因为这会使黑客更难滥用API。
但是，您确实需要解释一些必要的信息，例如：
- 如何获取 API 密钥
- 如何对请求进行身份验证
- 与无效身份验证相关的错误消息
- 身份验证信息的敏感性
- 令牌过期时间
如果您有公钥和私钥，则应说明每个密钥的使用位置，并注意不应共享私钥。如果不同的许可证层提供对 API 调用的不同访问权限，则应在授权部分或其他位置显式使用这些许可层。
由于在开发人员开始使用 API 之前，API 密钥部分通常是必不可少的，因此此部分需要显示在帮助的开头。
授权部分的示例
以下是 API 文档中授权部分的几个示例。
发送网格
发送网格 API 密钥
发送网格提供了 API 密钥的详细说明，从基础知识开始，解释“什么是 API 密钥？根据上下文，有关 API 密钥的主题会与其他帐户管理主题一起显示。
唽
推特授权
对于 Twitter，由于 OAuth 2.0 授权要求稍微复杂一些，因此需要提供一个详细的示例。
亚马逊网络服务
亚马逊授权
亚马逊示例使用 HMAC。该过程非常复杂，包括一个完整的图表来显示用户需要执行的步骤。
投递箱
投递箱授权
与推特一样，丢卡也使用OAuth 2.0。他们的文档不仅包括一个图表，还包括两个图表和对过程的扩展解释。
有授权的活动
使用您确定的开源项目，确定有关 API 请求的授权信息。回答以下问题：
- 向 API 发出请求需要什么样的授权？
- 授权中是否有不同的访问级别（例如，免费层和专业层）决定了您可以发出的请求数或可以访问的信息类型？
- 您是否能够获得 API 密钥或对 API 进行测试调用所需的任何授权方法？
- 如何将有关授权的信息集成到入门教程中？
到目前为止，您在本课程中的进度：43%
70/162 页完成。只剩下 92 页了。
