API 授权方法

引言#

在当今世界中，API 是现代应用程序的支柱。它们是从后端服务访问数据和功能的主要途径。API 允许来自不同方的不同软件系统进行通信和共享数据，使得它们对企业至关重要。然而，API 也是攻击者的常见目标。API 保护的需求比以往更强烈。

API 保护是防止未经授权访问、滥用和攻击的过程。它是任何 API 策略的关键组成部分。在本文中，我们将探讨三种常见的 API 保护机制：API 密钥、基本身份验证和 OAuth JWT 令牌。最后，我们还将展示 Logto 如何使用 OAuth JWT 令牌保护你的 API。

API 密钥#

API 密钥是保护 API 的最简单和最广泛使用的方法。API 密钥是由 API 提供者生成并与授权用户共享的一长串字符。访问 API 时，该密钥必须包含在请求头中。API 密钥对于基本安全需求来说简单有效。例如，诸如 Google Maps API 和 AWS 等流行服务提供 API 密钥来控制访问和监控使用情况。然而，在安全性方面，它们有其局限性。它们通常用于机器对机器的通信。

e.g.

优点：#

• 实现简单：API 密钥易于实现和使用。它们涉及将密钥附加到请求头中，使得它成为开发者和客户端易于理解和使用的方法。
• 易于监控：API 密钥易于监控。你可以跟踪每个密钥的使用情况，并在必要时撤销它们。
• 有效的速率限制：API 密钥在速率限制方面效果显著。你可以对每个密钥的请求次数设置限制，以防止滥用。
• 适用于非敏感数据：API 密钥适用于非敏感数据或公开可用的 API，这些场景的安全要求较低。

缺点：#

• 安全性有限：API 密钥对于敏感数据来说不够安全，特别是在客户端应用程序中。它们通常用于机器对机器的通信。
• 不适合用户身份验证：API 密钥与应用程序或系统绑定，而不是与个人用户绑定，因此难以识别特定用户或跟踪其行为。
• 令牌无过期：API 密钥通常是静态的，不会过期。如果密钥被泄露，可能会被无限期地滥用，除非手动重新生成。

基本身份验证#

基本身份验证是保护 API 的另一种常见方法。它是构建在 HTTP 协议中的一种简单验证方案。它涉及在请求头中发送用户名和密码。服务器在验证凭据后会返回请求的资源。例如，许多 web 应用程序和 RESTful API 使用基本身份验证作为快速简单的用户验证方式。基本身份验证比 API 密钥更安全，因为它使用用户名和密码而不是静态密钥。然而，它对于敏感数据来说仍然不够安全。由于客户端凭据以明文方式传输，容易被拦截。基本身份验证适用于网络连接安全的内部系统，例如机器对机器的通信。

e.g.

或

优点：#

• 更强的安全性：基本身份验证比 API 密钥更安全，因为它使用用户名和密码而不是静态密钥。
• 广泛支持：基本身份验证被大多数 web 服务器和浏览器广泛采用和支持。
• 简单性：与 API 密钥类似，基本身份验证相对简单设置和使用。

缺点：#

• 凭据暴露：基本身份验证以明文方式发送凭据，如果不在安全连接（HTTPS）上使用，容易被拦截。
• 无令牌过期：基本身份验证不支持令牌过期功能。如果令牌被泄露，可能会被无限期地滥用，除非手动重新生成。

OAuth JWT 令牌#

JSON Web Token (JWT)，由 RFC 7519 定义，是一种用于在各方之间作为 JSON 对象安全传输信息的开放标准。它通常用于 web 应用程序和 API 中的身份验证和授权。

一个签名的 JWT 格式如下：

它由三部分组成，用 . 分隔：头部、负载和签名。

以下是一个 JWT 示例：

• 头部：包含关于令牌类型和用于签名的哈希算法的信息。
• 负载：包含关于用户的声明（即声明）和其他数据。
• 签名：是头部和负载的哈希值，用密钥签名。

OAuth 是一个全面的 API 安全和访问委托开放标准，常用作客户端用户授权网站或应用程序访问其在其他网站上的信息，而无需提供密码的方式。

与 JWT 一起使用时，OAuth JWT 令牌提供了强大的安全解决方案。与每个请求传输例如用户名和密码的敏感信息不同，OAuth JWT 令牌会在成功验证后发放给授权客户端。这些令牌包含关于用户及其权限的信息。此外，JWT 令牌经过数字签名以防篡改，并且可以到期。这提供了额外的安全层。

OAuth JWT 令牌的一个重要优点是其灵活性。它们可以用于各种类型的应用程序，包括 web 和移动应用程序、单点登录解决方案等。例如，Facebook、Twitter 和 LinkedIn 等主要社交媒体平台使用 OAuth JWT 令牌来验证用户并安全地允许第三方应用程序访问用户数据。

优点：#

• 增强的安全性：OAuth JWT 令牌提供更高水平的安全性。它们经过数字签名并且可以加密，从而降低了未经授权的访问和数据篡改的风险。
• 用户身份和访问控制：JWT 令牌可以携带用户身份信息，并包含声明，指明用户被授权访问的操作或资源。
• 精细的访问控制：JWT 令牌可以用于实现精细的访问控制。例如，你可以指定用户可以访问哪些资源以及他们可以对这些资源执行哪些操作。
• 令牌到期：OAuth JWT 令牌可以设置为在一定时间后过期，从而减少滥用风险。

缺点：#

• 复杂性：OAuth JWT 令牌比 API 密钥和基本身份验证更复杂。它们需要额外的步骤来设置和使用。
• 令牌管理：OAuth JWT 令牌需要进行管理，并在必要时进行撤销。对于拥有大量用户和客户端的大规模应用程序来说，这可能具有挑战性。
• 资源消耗：生成和验证令牌可能会带来一些性能开销，这在高流量场景中可能是一个问题。

Logto API 保护#

身份验证方法的选择取决于应用程序的具体要求和安全性考虑。API 密钥虽然简单，但安全性较低；基本身份验证提供了更强的安全性，但缺乏用户身份功能；而 OAuth JWT 令牌则提供了强大的安全性和用户身份功能，但增加了实现和管理的复杂性。

Logto 提供了一种简单且安全的方式来使用 OAuth JWT 令牌保护你的 API。它支持 OAuth 2.0 和 OpenID Connect (OIDC) 标准，使你可以选择最适合你需求的身份验证方法。你可以使用 client_credentials 流程进行机器对机器的通信，使用 authorization_code 流程进行 web 应用程序的通信。

机器对机器的通信#

Logto 对机器对机器类型的应用程序使用 client_credentials 流程。此流程适用于后端服务器之间的通信，其中客户端是能够安全存储客户端凭据的机密客户端。它也被称为“两阶段 OAuth”，因为它不涉及用户。客户端凭据直接用作授权授予以获取访问令牌。

集成过程简单明了：

1. 在 Logto 控制台中创建一个 API 资源。
2. 在 Logto 控制台中创建一个机器对机器的客户端。
3. 向 Logto 令牌终端发送请求以获取访问令牌。

4. 使用访问令牌访问受保护的资源。

请查看我们的machine-to-machine integration documentation，获取更多详细信息。

Web 应用程序#

对于诸如 web 应用程序之类的公共客户端，Logto 使用 authorization_code 流程来验证用户。此流程适用于客户端为公共客户端而无法安全存储客户端凭据的 web 应用程序。它也被称为“三阶段 OAuth”，因为它涉及用户。用户被重定向到授权服务器以进行身份验证并授权客户端。然后客户端使用授权码来获取访问令牌。

相比机器对机器流程，集成流程稍微复杂一些：

请查看我们的Protect your Express.js API with JWT and Logto文章，作为一个集成 Logto 和 React 并使用 JWT 令牌访问你的 Express 服务器 API 的全面示例。