简化 API 身份验证与个人访问令牌 — 更安全的API令牌

解释个人访问令牌（PATs）的工作原理、使用时机、如何在服务中支持PAT功能，以及它们与API密钥、API令牌、Bearer令牌、OAuth令牌和密码的区别。

Ran

Product & Design

2/20/2025

不要在用户认证上浪费数周时间

使用 Logto 更快地发布安全应用。几分钟内集成用户认证，专注于您的核心产品。

立即开始

个人访问令牌（PATs）是用户生成的令牌，用于替代API调用的密码。专为特定用户设计，PATs 提供对资源的安全和受控访问。

轻松身份验证，细粒度访问控制，精简工作流程。 这就是为什么全球的开发者和产品团队依赖个人访问令牌来提升生产力，不管是管理 CI/CD 流水线、集成 API，还是访问工具。

对 PAT 的工作原理、优点或使用时机感到好奇？本指南为你解答。

什么是个人访问令牌？

个人访问令牌是一种临时的、安全的认证方式，通过 API 访问个人资源和服务。它主要用于开发者，使访问 API 或自动化工作流程等任务变得更简单和高效。

可以将个人访问令牌视为 API 访问的“钥匙”，无需密码。与密码不同，PATs拥有特定的权限和到期日期，确保它们仅用于预定目的，如访问用户档案或计费系统，但不涉及管理员控制。

个人访问令牌的关键特性：

开发者友好：个人访问令牌比完整的 OAuth 工作流程更易于管理，适用于脚本、自动化或 CI/CD 流水线。
多个令牌：用户可以生成和管理多个个人访问令牌，每个都专用于特定的服务或用途。
用户特定访问：与全局 API 密钥不同，个人访问令牌与个人用户帐户关联。这意味着团队成员可能需要为共享访问创建单独的令牌。
细粒度权限：使用个人访问令牌，你可以定义特定的作用域，仅授予所需资源和操作的访问权限。
时间限定访问：个人访问令牌可以配置到期日期，减少曝光时的风险窗口。
轻松撤消：与密码不同，个人访问令牌可以被撤消或再生成，而不影响帐户的主要凭证。

个人访问令牌 vs. Bearer 令牌 vs. API 令牌

个人访问令牌是一种 API 令牌：个人访问令牌是一种与用户帐户关联的用户级 API 令牌。它允许代表用户访问系统资源。PATs比传统 API 密钥更安全，因为它们允许对权限进行精细控制，比如限制访问特定的存储库或组织，并且可以为增加安全性而包含到期日期。
个人访问令牌可以用作 Bearer 令牌：Bearer 令牌是一种授权 API 请求的方法，通常使用 OAuth 或 JWT 等协议动态创建。个人访问令牌是静态版本的 Bearer 令牌，由用户手动生成（例如，在 GitHub 上）。例如，当使用 GitHub PAT 进行 API 调用时，你将其包含在请求头中作为 authorization: bearer <your-pat>。在这种情况下，PAT 作为 Bearer 令牌。
API 令牌是个广泛术语：API 令牌是用于认证 API 请求的任何令牌的总称。它包括不同类型，如 Bearer 令牌、OAuth 令牌和个人访问令牌。PATs 和 Bearer 令牌只是特定类型的 API 令牌。

选择你的 AuthN 和 AuthZ 机制

在采用个人访问令牌之前，了解它在更广泛的身份验证方法中的角色是至关重要的。面对多种机制的选择，了解它们的比较是重要的。以下是一个详尽的表格，列出了个人访问令牌（PATs）、密码、API 密钥和OAuth 令牌之间的关键区别，以帮助你做出明智的决定。

个人访问令牌： 轻量级的身份验证方法，适用于自动化任务或 API 访问。它提供精确、细粒度的权限控制，确保安全和定制的访问。
密码： 传统的身份验证方法，用于通过用户界面访问个人账户。它授予与账户所有者相同的权限，无法提供额外的细粒度控制。
OAuth 令牌： 最安全的第三方服务受限访问方法。它允许用户定义特定的访问范围，而无需暴露其凭证，确保安全性和灵活性。
API 密钥： 通常用于自动化 API 访问，API 密钥与服务帐户而非个人帐户关联。然而，它们缺乏 PATs 或 OAuth 提供的详细权限控制。

特性	密码	个人访问令牌	OAuth 令牌	API 密钥
定义	用户通过身份标识和密码进行身份验证。	用于访问特定资源或API的令牌，通常具有有限的权限。	一个系统，用户无需分享凭据即可授予第三方应用访问其数据。例如，Google 登录	客户端用于验证API请求的唯一字符串。
范围限制	登录后通常授予对用户帐户的完全访问权限。	允许进行细粒度权限控制。	允许用户定义第三方应用可以访问的内容。	通常授予对特定API资源的访问权限。没有细粒度控制。
撤销	无法撤销而不更改密码，影响多个服务。	用户或管理员轻松撤销。	可以撤销而不影响用户凭证。	可以在API服务级别撤销或再生成。
到期	除非用户更改，否则不会过期。	通常是长期存在的，但可以配置为过期。	访问令牌在设定时间后过期；刷新令牌可以延长访问。	通常是长期存在的，但可以由API供应商旋转或限制。
易用性	容易记住，但处理不当时有风险。	生成简单，适用于自动化任务。	需要初始用户互动，但提供安全的访问委托。	在请求中易于使用，但不适用于面向用户的身份验证。
最佳适用对象	客户端用户的基本登录和验证。	自动化、受限 API 资源访问以及 CI/CD 流水线开发。	第三方应用无需存储密码即可获得对用户数据的有限访问。	后端服务、服务器间通信和公共API。
安全风险	如果被盗，可以完全访问账户。	如果泄露，则仅能访问指定资源。可以轻松撤销。	如果泄露，第三方应用可以在授予的范围内执行操作。	如果被盗，通常用于服务器间访问。

个人访问令牌如何工作？

个人访问令牌的工作方式与 OAuth 访问令牌类似，但通常是没有关于其内容的用户可读数据的字符串。当你使用像 GitHub 这样的服务进行身份验证时，你可以生成一个与用户帐户关联的 PAT 并为其分配特定权限。此令牌作为进行请求时使用密码的安全替代方案，例如通过 API 访问私人存储库。

通常，PAT 包含在请求头中，如下例所示：

通过这种方式发送 PAT，服务可以验证你的身份，评估与你的令牌相关的权限，并提供请求的数据或执行指定的操作。

如何使用个人访问令牌？

生成个人访问令牌：首先通过你所使用的平台创建一个个人访问令牌，并选择特定的作用域来定义其访问权限（作用域）。
认证 API 请求：准备好个人访问令牌后，使用它对需要安全访问的服务进行请求认证。在API请求的授权头中将令牌作为Bearer令牌包含。
撤销个人访问令牌：如果需要停用令牌，只需通过平台的身份验证设置撤销。一旦撤销，使用该令牌进行的任何API请求将自动被拒绝。

什么时候应该使用个人访问令牌？

个人访问令牌在需要提供对API的安全、开发者友好和范围控制的访问的情况下表现出色。以下是一些理想的使用场景：

自动化任务： 适合需要从 API 中获取数据的脚本或工具，无需开发者嵌入敏感凭据。
细粒度权限控制： 通过授予脚本或工具有限的权限，如访问特定存储库，在不暴露完全帐户权限的情况下启用精确访问。
临时访问： 适用于时间敏感的情况，通过限制访问持续时间来降低安全风险。
简化开发者访问： 一种方便的方式，授予个人开发者访问权，而无需配置完整的 OAuth 授权流程的复杂性。
第三方集成： 通过限制对特定预定义操作的访问优化与外部工具的功能。例如，当公司使用项目管理工具时，第三方集成可以允许团队成员直接从 Slack 聊天中创建任务或更新状态，而无需完整访问项目管理工具。

自2013年起，GitHub 推动了个人访问令牌的使用，因其简单和灵活而受欢迎。许多开发者工具和 SaaS 平台支持 PATs，使得它们易于使用，并成为开发者的首选：