在当今 IT 驱动型经济中，网络 API 正越来越多地被全世界使用。 您可能自己使用或创建了 API。 API 处理大量数据 – 软件服务组织特别需要保护这些数据的主要关注点之一。 其理念是数据应稳定且安全，并且只能由目标用户访问。 时间、速度和性能对 API 也很重要。 在这篇文章中，我们将讨论世界各地 IT 组织广泛使用的不同 API 身份验证和授权方法。
身份验证与授权
如果您曾经处理过 API，则始终只能看到授权标头，而看不到身份验证标头。 你有没有想过为什么？ 只需使用任何网络嗅探工具，如Fiddler/Wireshark，或使用API 测试工具 并检查应用程序的API。 无论您看到 API 的标头还是正文，API 请求始终可以找到授权。 因此，在解释 API 为什么只有授权而不是身份验证之前，让我们先解释身份验证和授权的区别。
认证
如果用户是使用该服务的合适的人，则身份验证只是验证用户。 让我们用一个简单的例子进一步解释它。 假设你和家人一起参观了镇上的一家餐馆。 你打开餐厅的门，受到经理的欢迎。 但是你不想坐在餐厅的公共餐厅里，你想和家人坐在私人房间里，你必须为此预订。 您让经理知道，他们确认您有预订，允许您坐在为家庭保留的餐厅私人部分。 因此，这就是我们所谓的身份验证。 餐厅经理允许您与家人坐在私人用餐的地方，并有效预订。 我们可以说，保留称为身份验证密钥。
授权
现在，您可以进入私人房间，您可以使用为私人用餐者保留的服务等。 你被授权做这一切，但如果你进入餐厅的厨房，打开他们的冰箱，他们可能会告诉你不允许在这个地区。 因此，这称为授权。 因此，您可以进入，但进入餐厅后，您无权进入某些地区，也无权进入其他区域。 这就是授权。
现在，当涉及到网站时，任何人都可以进入公共网站登录 页面。 就像任何人都可以进入餐厅一样。 没人会阻止你的 当您使用网站 用户名和密码 登录时，您将通过身份验证并可以进入网站。 同样，您使用预订访问餐厅中保留的私人餐桌的方式。 但是，在输入之后和身份验证之后，您可以访问某些部分，但您可能无法访问一些其他部分，这些部分与网站的管理部分一样。 因此，这是身份验证和授权之间的一个非常基本的区别。
现在，回到我们的问题。 我们总是在 API 中看到授权，为什么如此？ 如果查看 API，它将指向该地址指向应用程序上特定函数或资源的终点。 例如，我们可以说应用程序背面的模块。 当您实际尝试单独访问应用程序中的特定资源时，更合适地调用它作为您的授权，尽管会有身份验证来验证您的身份。 第一步始终是身份验证。
HTTP 身份验证的类型
由于我们已经介绍了身份验证和授权的区别，因此现在我们将讨论不同类型的 API 身份验证。 API 身份验证方法根据它们使用的技术而有所不同。 身份验证非常重要，因为它们与系统安全性直接相关。 这就是为什么优先级始终转到任何系统中的 HTTP 身份验证。
我们将重点介绍向 API 添加安全性的五个主要机制 — 基本、API 密钥、承载者、OAuth1.0/OAuth 2.0 和 OpenID 连接。 我们将确定它们做什么，它们是如何工作的，以及每种方法的优缺点。 最后，我们将演示使用 LoadView 进行身份验证的 API 的负载测试。
基本身份验证
HTTP基本身份验证现在很少被 IT行业使用，因为它很容易被黑客入侵，但这是最容易实现的方法。 API 将沿正文发送用户名和密码。 凭据将采用加密方法（如 Base64） 进行编码。这会将用户名和密码转换为传输的加密格式。
由于它使用标头进行凭据传输，因此没有其他复杂的安全措施。 甚至没有会话 ID 或 Cookie。
请求标题中的基本身份验证示例：
授权：基本 Cg4sOnOlY8KyPQ=
摘要身份验证
摘要访问身份验证比基本身份验证更复杂和高级。 摘要使用用户密码和其他属性的组合来创建 MD5 哈希。 然后，这将发送到服务器进行身份验证。 它比其他安全机制更高级，因为它将凭据作为哈希发送。 它最初是作为 RFC 2069 的一部分创建的，后来在 RFC 2617 中添加了安全增强功能。
在摘要身份验证中，是服务器发现尝试访问资源的客户端。 服务器将生成一个唯一值，称为“nonce”。 稍后，资源请求者将使用此唯一值生成 MD5 哈希，该哈希将由服务器验证。
API 密钥
与基本身份验证相比，API密钥得到了广泛的应用。 您可以在移动应用程序和 Web 应用程序中看到它。 创建 API 密钥在某种程度上是为了 解决 与 API 基本机制相关的安全漏洞。 在 API 密钥中，使用用户名和密码进行身份验证后，服务器端将生成唯一值。 它将分配给用户。 通常，此唯一值基于 IP 地址和不同的用户属性生成。 大多数时候，开发人员将在授权标头中发送 API 密钥。
API 密钥的示例
api_key： d670d200234faf5480aa11529b01d732
与所有其他安全机制相比，使用 API 密钥肯定有很多优点。 首先，API 密钥简单，安全性更好。 缺点是任何人都可以使用任何网络嗅探工具来拾取此安全密钥。 这可能导致整个应用程序的安全问题。
承载
记者的意思是”携带或持有某样东西的人或东西”。 正如名称建议的那样，它是一个涉及安全令牌的 HTTP 身份验证方案。 安全令牌的持有者将访问某些功能或 URL。 承载令牌通常由服务器生成，以响应客户端登录请求。 用户从服务器获得承载令牌后，在发出进一步请求时，他们必须将令牌与授权标头一起发送。
承载身份验证示例
授权：
承载 eyjhbgcioijiuzi1niisinr5cci6ikxvcj9. eyjodrwoi8vc2nozw1hcy54bwxb2fwlm9yzy93cy8ymda1lza1l2lkzw50axr5l2nsywltcy9uyw1lijoimntuyztu0njutntjzi00ztu2ltk2ndutndu4njg0 jjvjnwqyiiwizxhwioxntkzoty3odq0lcjpc3mioijodhrwolxcd3d3lnnvdwxib29rlm1wiyxkki joiahr0cdpcxhd3dy5zb3vsym9vay5tzj9. adcayn8u5tn68evgugplybkcgc8ohgxm7p45tnpxvc
它最初是作为 RFC-6750 中的 OAuth2.0 的一部分创建的。 与所有其他安全机制相比，使用无记名令牌肯定有很多优点。 在安全性方面，承载令牌更好。
OAuth 1.0 和 OAuth 2.0
OAuth 是一种更安全的授权 协议 。 OAuth 提供了简单性，同时为应用程序提供了授权流。 例如，用户通常使用 OAuth 使用他们的 Google、Microsoft、Facebook、Slack 帐户登录第三方网站，而不公开其凭据。
OAuth 1.0 被怀疑存在安全漏洞，不再受支持。 OAuth 2.0 具有高级安全功能，是个人用户帐户标识和身份验证的最佳选择。 OAuth 2.0 允许用户与应用程序共享其特定属性，同时保留其凭据和其他信息机密。 OAuth 1.0 比 OAuth 2.0 复杂得多，安全程度也更低。 OAuth2.0 中最大的变化是无需使用键哈希对每个调用进行签名。
基本上，OAuth 由两个令牌组成以进行验证;身份验证令牌和会话令牌。 身份验证令牌的工作方式与 API 密钥安全协议一样，应用程序将进行身份验证以访问用户数据。 会话令牌用于维护用户会话，并在会话令牌过期时检索新的身份验证令牌。 OAuth 2.0 结合了身份验证和授权，为应用程序提供更多的安全性。
在 OAuth 中，用户将使用凭据访问应用程序。 然后，应用程序将请求身份验证令牌。 请求者会将此请求发送到身份验证服务器，如果凭据正确，该服务器将允许此身份验证。 此身份验证令牌可随时独立于用户进行验证。 这将使 OAuth 成为一个比其他 HTTP 身份验证更安全的机制。 OAuth 的主要缺点之一是实现的复杂性。 您应该在 OAuth 流中拥有良好的知识，以将其与您的应用程序集成。
打开 ID 连接
OpenID 连接是 OAuth 2.0 协议的扩展。 它根据授权服务器执行的身份验证验证客户端标识。 此外，它可以获取有关客户端的用户配置文件信息。 OpenID 连接实际上解决了 OAuth 2.0 的很多缺点，并为最终用户和开发人员提供了更好的解决方案。
使用的最佳身份验证协议是什么？
HTTP 基本身份验证是应用程序中最容易实现的，但也一点也不安全。 凭据经过编码，但以纯文本形式发送。 摘要身份验证通过以哈希格式发送数据来改进基本身份验证。 但是MD5算法哈希并不复杂，很容易被黑客入侵。 API 密钥和承载项几乎相似，并提供了上述更好的安全性。
OAuth 协议确保任何黑客都无法获取客户端信息。 即使应用程序也无法获取客户端配置文件凭据和私有信息。 OpenID Connect为应用程序建立协议，以使用 RESTful API访问客户端的属性。 OpenID Connect 通过引入新令牌来扩展 OAuth 2.0 授权令牌流。 基本上，OpenID 连接是作为 OAuth 2.0 的扩展实现的。
使用 LoadView 测试需要身份验证的 API
在本节中，我们将使用 LoadView 实现 HTTP API 身份验证。 LoadView 允许您非常轻松、高效地执行这些任务。 负载视图为 API 身份验证负载测试提供了两个选项：
API 身份验证：选项一
如果您有权访问应用程序，我们可以使用任何网络工具获取 API 请求。 这是最简单的方法。 我们将展示一个使用 LoadView 配置上述每个 HTTP 身份验证机制的快速演示
注意：您可以从开发团队获取 API 服务器请求详细信息和正文数据详细信息，或使用任何网络嗅探工具捕获它。
第 1 步：选择负载测试类型
登录到 LoadView 并在”选择负载测试类型”下，选择HTTP/S。
第 2 步：配置 API
下一个屏幕将要求您配置 API。 在这里，我们将向您展示如何在 LoadView 中配置不同的 HTTP 身份验证机制。
基本身份验证
API 密钥
承载令牌
奥思 2.0
OAuth 2.0 和打开 ID 连接配置更为复杂。 我会告诉你OAuth2.0的演示。 有一个简单的方法来做Auth 2.0身份验证，将在本节后解释。
第 1 步：身份验证服务器
配置 OAuth 身份验证服务器详细信息。
第 2 步：凭据
输入凭据并单击登录。 身份验证服务器使用代码作为 URL 参数将用户重定向到您的网站。
第 3 步：服务器信息
API 服务器向身份验证服务器询问用户信息。
第 4 步：访问令牌
API 服务器标识用户，并响应访问令牌。 然后，用户在每个请求上将访问令牌发送到 API 服务器。 API 服务器验证并赋予对应用程序的访问权限。
API 身份验证：选项 2
如果第一个选项不可行，您可以使用 EveryStep Web 记录 器录制工具 进行录制。 你可以通过网络访问它，使用录音机更容易和有效。 此外，您不需要学习不同的身份验证机制。 在这里，我们将演示如何使用 LoadView 和使用 EveryStep Web 记录器进行负载测试。 应用程序使用 OAuth 2.0 进行身份验证。
第 1 步：录制新脚本
登录到 LoadView 并在”选择 负载测试类型”下，选择 Web 应用程序。 或者只需打开 “每步网络记录器“，输入您的 URL，然后开始录制。
第 2 步：导航到登录功能
就是这样。 您已记录应用程序身份验证，具有 OAuth 2.0。 重播录制的脚本，并确保一切按预期工作。 很简单吗？ 录制完成后，您可以转到执行加载测试的下一步。
最后的想法：加载需要身份验证的 Web API
使用任何性能测试工具，关联 HTTP 身份验证机制并非易事。 您需要有实践经验和深入了解身份验证流的工作原理。 此外，对登录功能进行负载测试也非常重要。 如果您的登录模块无法满足预期的并发用户负载，这将是您的业务的巨大损失。 应用程序登录是应用程序功能的关键部分。 如果您正在 为您的 Web API 寻找一个好的端到端性能测试解决方案，您一定会喜欢 LoadView。 今天就去试一试吧！