编程认证：API 密钥、个人访问令牌和 OAuth 客户端凭证流程

背景#

在软件开发中，当我们需要通过 CLI 命令以编程方式访问 API 资源，或在后端服务之间建立通信时，我们开发人员通常使用三种广泛使用的认证机制：API 密钥、个人访问令牌 (PAT) 和 OAuth 客户端凭证流程（在 Logto 中被称为机器对机器）。但它们之间有什么区别呢？每种方法的最佳应用场景是什么？在这篇博客文章中，我们将深入探讨它们的相似性、差异性，并提供何时在不同场景下使用每种方法的见解。

定义#

• API 密钥：一个简单的字符串，可以验证你对 API 资源的请求。
• 个人访问令牌 (PAT)：也是一个简单的字符串，但在使用它进行 API 资源验证时，表示的是一个用户。这是用户的一种委托。
• Logto 机器对机器 (Logto M2M)：一个标准的 OAuth 客户端凭证流程，要求事先注册客户端，并需要使用客户端 ID 和密钥来交换访问令牌。因此，Logto M2M 凭据代表了一个受信任的客户端，OAuth 客户端凭证流的性质使其在使用时相对复杂。

相似性#

1. 认证目的#

• API 密钥、PAT 和 Logto M2M 的主要目的都是验证用户或应用程序以访问特定服务或资源。它们充当证明请求者身份的凭据，通常用于 CLI 命令或后端对后端的通信场景。

2. 安全措施#

• 这三种认证方法都应以安全为基础进行处理。开发人员必须确保安全的存储和传输以防止未经授权的访问。

差异性#

1. 用户上下文#

• API 密钥不识别主体，也不提供任何授权信息。因此，API 密钥通常用于匿名访问公共数据或资源。并非所有服务都支持使用 API 密钥。
• PAT 是用户身份，在请求 API 资源时代表你。在某些系统中，PAT 不允许访问某些服务。例如，将 NuGet 包发布到 Azure Artifacts 提要。
• Logto M2M 凭据只能由受信任的客户端使用。客户端必须事先注册以进行认证。使用 Logto M2M 凭据时，它表示的是受信任的客户端，而不是使用它的用户。

2. 权限粒度#

• PAT 和 Logto M2M 凭据通常提供比 API 密钥更细粒度的权限控制，允许对可以执行的操作进行精细控制。

3. 令牌格式#

• API 密钥和 PAT 通常是不可透明的字符串，简单明了。
• 通过 Logto M2M 机制颁发的访问令牌通常是 JWT 格式。

4. 授权流程#

• API 密钥和 PAT 是系统生成的不可透明字符串，在流程中没有认证流程。例如，你可以这样调用 Google Cloud 自然语言 API：

• Logto M2M 利用标准的 OAuth 2.0 客户端凭证流程。每个客户端必须事先获得客户端 ID 和客户端密钥，之后客户端可以用它们来交换访问令牌。然后客户端使用访问令牌访问 API 资源。

何时使用#

API 密钥#

• 服务对服务通信：API 密钥适用于应用程序需要通过 CLI 直接与 API 通信的场景。例如，调用 OpenAI API。
• 公共 API：在向公众公开 API 时，API 密钥提供了一种简单的访问控制方法。
• 简化设置：对于快速和简单的认证需求，特别是在开发阶段。与 Logto M2M 不同，API 密钥不需要事先注册客户端，也不需要交换访问令牌。你只需在请求中将你的 API 密钥作为参数传递即可。

个人访问令牌 (PAT)#

• 用户特定动作：当应用程序需要代表用户执行动作时。
• 精细访问控制（用户）：当需要精准控制用户可以执行的操作时。

Logto 机器对机器 (Logto M2M)#

• 安全性：Logto M2M 适用于只允许受信任客户端访问后端服务的场景。
• 精细访问控制（客户端）：当需要对应用程序可以执行的操作进行精准控制时。

结论#

总之，在 API 密钥、PAT 和 Logto M2M 之间的选择取决于你的应用程序的具体需求，无论是涉及用户特定的操作、机器对机器通信，还是两者的结合。评估安全性和功能需求以确定最适合你的用例的认证方法。

Logto M2M 机制允许用户通过 RBAC（基于角色的访问控制）功能设置精细的访问控制。我们也计划在不久的将来支持 API 密钥和 PAT。请留意我们的功能更新！