简体中文
  • api
  • security
  • authentication
  • PAT
  • API Key
  • machine-to-machine

个人访问令牌、机器对机器认证和 API 密钥的定义及其实际场景

了解个人访问令牌 (PATs)、机器对机器 (M2M) 认证和 API 密钥之间的区别，以及如何使用它们。

Guamian
Guamian
Product & Design

如果你正在构建一个软件或 SaaS 产品，你通常会遇到一个广泛的用例或功能需求：API 请求。尤其是大型企业客户可能希望在个人或组织级别上以编程方式访问资源。

在这种情况下，通常需要 API 密钥、个人访问令牌 (PATs) 和机器对机器 (M2M) 认证。在本文中，我们将探讨这些方法之间的差异，以及它们在开发面向企业的产品时如何被开发者使用。

相似之处

让我们先来看看这三者之间的相似之处。

  1. 安全目的：这三种方法都用于保护和控制对 API、服务或资源的访问。它们都作为身份验证和/或授权的手段。
  2. 基于令牌的方式：每种方法通常都涉及使用一个唯一的字符串或令牌进行识别。这些令牌通常随 API 请求一起发送，通常在头部或作为查询参数。
  3. 可撤销：如果令牌或密钥被泄露或不再需要，它们可以在所有这三种方法中被撤销或作废。这使得在不更改底层系统的情况下快速做出安全响应成为可能。
  4. 可编程访问：所有这三种方法都促进了对 API 或服务的编程访问。它们使不同系统或应用程序之间的自动化和集成成为可能。
  5. 可审计：这些身份验证方法的使用情况可以被记录和审计。这使得对 API 访问的跟踪、可疑活动的监控和合规报告成为可能。
  6. 适应访问控制：所有这三种方法都可以在不同级别的访问控制和权限下实施。它们可以适应不同的安全模型和架构需求。
  7. 协议独立性：虽然这些方法通常与 REST API 一起使用，但它们可以应用于各种类型的 API 和协议。

理解这些相似之处有助于识别这些身份验证方法的共同基础。它们的差异允许你为特定的用例和安全要求选择最合适的解决方案。

现在，让我们讨论它们的差异，重点是它们的用例以及何时使用每种方法。

差异

API 密钥

API 密钥用于识别和授权调用应用程序或服务。它们通常是长期有效的，且在更新之前是静态的，并且通常具有固定的权限集。它们主要用于服务器到服务器的通信或访问公共数据，这些令牌通常不代表特定的用户。

API 密钥如何工作？

API 密钥由 API 提供者发布，并交给已注册的 API 消费者 [1]，消费者在每次请求中都包含它。然后，API 服务器检查 API 密钥以验证消费者的身份，然后返回所请求的数据。

API 密钥不如其他形式的 API 身份验证（如 OAuth 和 JWT）有效，但它们仍然在帮助 API 生产者监控使用情况的同时，保护敏感数据的安全方面发挥着重要作用。

[1]: API 消费者指的是与 API 交互以访问其功能或数据的任何应用程序、服务或用户。它们向 API 发送请求，以执行诸如检索、创建、更新或删除资源等操作。API 消费者可以是 Web 应用程序、移动应用程序、其他服务器，甚至是使用 API 与其他服务集成或在现有平台上构建新功能的个人开发者。

Postman：什么是 API 密钥？

用例

当人们讨论 API 密钥的用例时，通常提到自动化、数据共享、测试、开发和安全控制。然而，这些都是相当技术性的。在实际场景中，构建产品时最常见的目的是集成。

示例 1：与 Zapier 集成

Zapier：使用 API 密钥增加身份验证

Zapier 是一种流行的自动化工具，用于连接不同的 Web 应用程序。当将应用程序与 Zapier 集成时，API 密钥用于验证和授权对该应用程序 API 的访问。例如，如果你想在 CRM 系统和电子邮件营销工具之间自动化任务，你需要从 CRM 系统生成一个 API 密钥并提供给 Zapier。然后，此密钥用于验证来自 Zapier 对 CRM API 的请求，从而允许数据在两个系统之间安全地流动。

Zapier

示例 2：与 Stripe 集成

Stripe 利用 API 密钥与各种平台和应用程序进行安全集成。使用 开发者仪表盘 来创建、显示、删除和滚动 API 密钥。

Stripe

个人访问令牌 (PATs)

个人访问令牌是另一个相似的概念，但它代表特定用户的身份和权限，是在成功身份验证或登录后动态生成的，并且通常具有有限的生命周期但可以刷新。它们提供细粒度的访问控制来访问特定用户的数据和功能，并且通常用于 CLI 工具、脚本或个人 API 访问。

PATs 如何工作

  1. 创建和管理：用户通过各个平台中的账户设置来生成 PATs。
    • 例如，在 GitHub 上，用户可以创建具有特定权限和过期日期的细粒度或经典 PATs。
    • 在 Atlassian 产品（如 Jira 和 Confluence）中，用户可以在其个人信息设置中创建 PATs，指定令牌的名称和可选的过期日期。
  2. 使用：PATs 作为授权头中的持有者令牌使用。这意味着它们被包含在 HTTP 头部中，以验证请求的身份。
    • 它们使用户能够安全地访问 API 资源，允许根据令牌授予的权限执行创建、读取、更新和删除资源等操作。
    • PATs 可以在平台内的多个应用程序中使用，提供统一的访问和权限管理方式。
  3. 撤销和设置过期：
    • PATs 通过允许用户在令牌泄露后将其撤销，提供了增强的安全性，而无需更改账户密码。
    • 平台通常建议为 PATs 设置过期日期，以减少长期存在的令牌被滥用的风险。

用例

通常存在两种典型的情景，

自动化和脚本

这意味着当开发者使用 PAT 自动化从存储库向生产环境部署代码时，可以减少手动干预并确保一致性。

例如，GitHub 用户可以创建 PATs 以通过 HTTPS 验证 Git 操作并与 GitHub 的 REST API 交互。这对于需要自动化任务（如克隆存储库、推送提交或管理问题和拉取请求）的开发者非常有用。

与外部应用程序集成

这意味着使不同系统和应用程序之间的安全通信成为可能。这看起来类似于 API 密钥集成的情景，但 PAT 代表用户，而不是客户端或应用程序。

例如，项目经理使用 PAT 将项目管理工具与外部问题跟踪系统集成，允许无缝的数据交换和同步，如 Atlassian（Jira 和 Confluence）。

上述情景更像是开发者工具。那么，PATs 仅对这些类型的产品有用吗？不。下面是两个额外的示例：一个是 CMS 系统，另一个是生产力工具。

示例 1：Contentful

Contentful：个人访问令牌

Contentful 是一个无头 CMS 平台，提供 PATs 作为访问其内容管理 API (CMA) 的替代品。

主要特点包括：

  • 用户可以创建具有不同范围和权限的多个令牌。
  • 令牌与用户账户绑定，继承其权限。
  • PATs 对于开发和自动化尤其有用。

Contentful

示例 2：Airtable

创建个人访问令牌 | Airtable 支持

Airtable - 一个云协作平台，实施了用于 API 访问的 PATs。

他们的系统允许：

  • 创建带有不同范围和访问级别的多个令牌。
  • 令牌可以限制在特定的基础或工作区内。
  • 企业管理员可以创建具有跨组织更广泛访问权限的令牌。

Airtable

机器对机器 (M2M) 认证

M2M 旨在服务与服务之间的通信，而无需人工干预。它源于用户名和密码不足以保护服务，并且在有效的自动化中效率不高的这一理念。

机器对机器 (M2M) 应用程序现在采用客户端凭证流，这是在 OAuth 2.0 RFC 6749 授权协议 中定义的。它也可以支持类似的标准协议。是的，与 PATs 和 API 密钥相比，M2M 认证对开放标准要求更严格。

它验证应用程序或服务本身，而不是用户，并且通常实施 JWT（JSON Web 令牌）以进行无状态认证。这为服务之间在分布式系统中的相互交流提供了一种安全的方式。

机器对机器认证如何工作

它遵循类似的过程：

  1. 客户端凭证：每台机器（或服务）都有一个独特的客户端 ID 和密钥。
  2. 令牌请求：服务将这些凭证发送到授权服务器。
  3. 访问令牌：授权服务器在验证后发出访问令牌，通常是 JWT（JSON Web 令牌）。
  4. API 请求：服务使用此令牌对另一个服务的 API 请求进行身份验证和授权。
  5. 验证：接受服务在授予资源访问权之前验证该令牌。

用例

这是一个使用机器对机器 (M2M) 认证进行后端对后端通信的简要示例：

场景：服务 A 需要访问服务 B 的 API 数据。

  1. 设置：

    • 服务 A 作为客户端在授权服务器上注册。
    • 服务 A 被授予一个客户端 ID 和密钥。

  2. 身份验证：

    • 服务 A 请求授权服务器提供访问令牌：

  3. 令牌发放：

    • 授权服务器验证凭证并发放一个 JWT 访问令牌。

  4. API 请求：

    • 服务 A 使用此令牌向服务 B 请求数据：

  5. 验证：

    • 服务 B 使用授权服务器验证令牌。

  6. 响应：

    • 如果验证成功，服务 B 向服务 A 返回请求的数据。

此过程允许服务 A 和服务 B 之间在无需用户干预的情况下进行安全、自动化的通信，使用 OAuth 2.0 客户端凭证流。

设备对设备通信

设备对设备通信，特别是在物联网 (IoT) 背景下，严重依赖机器对机器 (M2M) 认证以确保数据交换的安全和效率。

例如，像智能家居设备一样，智能恒温器与中央家居自动化中心通信，以根据用户偏好调整温度设置。恒温器使用 M2M 认证来安全地向中心发送数据并接收命令，确保只有授权设备才能与家中的供暖系统进行交互。

关键总结

好的，你已经看完了这篇文章。我可以得到一个快速总结吗？当然！以下是关键点的概述：

  1. 范围：API 密钥是广泛的，PATs（个人访问令牌）是用户特定的，M2M（机器对机器）令牌是服务特定的。
  2. 生命周期：API 密钥是长期有效的，PATs 的生命周期较短，M2M 令牌则具有可变的生命周期。
  3. 表示形式：API 密钥是不可见的字符串，PATs 可以是不可见或结构化的，M2M 令牌通常使用 JWTs。
  4. 用例：API 密钥用于简单的 API 访问，PATs 用于用户中心的操作，M2M 令牌用于服务与服务之间的通信。
免费试用 Logto 云