什么是个人访问令牌（PAT）？更安全的 API 令牌

解释个人访问令牌（PATs）如何工作、何时使用、如何在你的服务中支持 API 认证，以及它们与 API 密钥、API 令牌、Bearer 令牌、OAuth 令牌和密码有何不同。

Ran

Product & Design

2/20/2025

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

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

立即开始

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

轻松认证。细粒度访问控制。简化工作流程。 这只是全球开发者和产品团队依赖个人访问令牌提升生产力的几个原因，不论是管理 CI/CD 流水线、集成 API 还是访问相关工具。

好奇 PAT 如何工作、有何优势、或应在什么时候使用？别担心，这份指南帮你搞定。

什么是个人访问令牌？

个人访问令牌是一种临时、安全的认证方式，可以通过 API 访问你的个人资源和服务。它主要被开发者用于简化诸如访问 API 或自动化流程等任务，提高效率。

你可以把个人访问令牌看作用于 API 访问的“钥匙”，无需再输入密码。与密码不同，PAT 具备特定权限和有效期，确保其仅被用于预期场景，比如访问用户资料或账单系统，但不会有管理员控制权。

个人访问令牌的主要特性：

对开发者友好：比完整的 OAuth 流程更易于管理，非常适合于脚本、自动化或 CI/CD 流水线使用。
多令牌管理：用户可以生成和管理多个 PAT，每个用于不同的服务或目的。
用户专属访问：与全局型 API 密钥不同，PAT 绑定到个人用户账号。这意味着团队成员需各自创建令牌用于共享访问。
细粒度权限：可以为 PAT 指定具体权限范围（scopes），只允许访问所需的资源与操作。
时效性控制：PAT 可设置过期日期，若被泄露也能缩短风险窗口。
便捷撤销：PAT 可随时撤销或重新生成，无需影响账号的主凭证。

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

个人访问令牌是 API 令牌的一种类型：PAT 属于与用户账号挂钩的 API 令牌类型，可以代表用户权限访问系统资源。比传统 API 密钥更安全，因为可以做权限控制细化，比如只授权特定仓库或组织，并且可设失效日期以提升安全性。
个人访问令牌可作为 Bearer 令牌使用：Bearer 令牌是用于授权 API 请求的一种方式，通常通过 OAuth 或 JWT 等协议动态创建。PAT 属于静态 Bearer 令牌，由用户手动生成（比如在 GitHub）。比如你用 GitHub PAT 进行 API 调用时，可以在请求头里加上 authorization: bearer <your-pat>，此时 PAT 就作为 Bearer 令牌使用。
API 令牌是广义的术语：API 令牌泛指一切用于 API 请求认证的令牌，包括 Bearer 令牌、OAuth 令牌和个人访问令牌。PAT 和 Bearer 令牌都归属于 API 令牌类别。

选择你的 AuthN 和 AuthZ 机制

采用个人访问令牌前，你应该理解它在整个认证方法生态里的角色。多种机制可选，了解它们的差异尤为重要。下表详细梳理了个人访问令牌（PAT）、密码、API 密钥与 OAuth 令牌之间的主要区别，帮助你做出明智选择。

个人访问令牌： 轻量级认证方式，适用于自动化任务或 API 访问。权限控制精确细致，确保访问安全且定制。
密码： 传统认证方式，通过用户界面访问个人账号。权限与账号所有者一致，无法细分。
OAuth 令牌： 授权第三方服务受限访问的最安全方式。允许用户设定精确定义的访问范围，保护凭证安全，并兼具灵活性。
API 密钥： 通常用于自动化 API 访问，API 密钥绑定服务账号而非个人账号，不过不支持 PAT 或 OAuth 那样的细致权限控制。

特性	密码	个人访问令牌	OAuth 令牌	API 密钥
定义	用户用标识和密码认证。	用于访问特定资源或 API 的令牌，通常带有限定权限。	用户无需分享账号凭证，授权第三方应用访问其数据。例如，用 Google 登录	客户端用于认证 API 请求的唯一字符串。
作用范围限制	通常一旦登录即获得用户账号全部权限。	可精确控制权限范围。	用户可定义第三方应用可访问哪些内容。	通常仅限访问特定 API 资源，无细粒度控制。
撤销	很难撤销，往往需要更换密码，会影响多项服务。	可由用户或管理员轻松撤销。	可撤销且不会影响用户主凭证。	可在 API 服务层级撤销或重置。
失效/过期	除非用户修改密码，否则一直有效。	常为长时效，但可配置过期。	访问令牌在设定时间后过期，刷新令牌可延长。	常为长时效，但可由 API 提供方轮换或限制。
易用度	容易记住，但泄露风险高。	生成和用于自动化任务都很简单。	需用户首次参与但能安全委托授权。	调用时易用，但不适合面向用户认证。
最佳用途	客户端用户的基础登录和验证。	自动化、受限 API 访问、CI/CD 流水线开发。	第三方应用需有限访问用户数据且不需存储密码。	后端服务、服务器间通信、以及公共 API。
安全风险	若被盗用，将能访问账号全部内容。	若泄露，仅能访问限定资源，且易于撤销。	若泄露，第三方应用只能按授权范围操作。	若被盗用，通常用于服务器间访问。

个人访问令牌工作机制？

个人访问令牌的使用方式与 OAuth 访问令牌类似，但通常仅为字符串且不含用户可读内容。你在类似 GitHub 这样的服务中，可以生成绑定到自己账号、带特定权限的 PAT。这个令牌可以安全地替代密码用于进行 API 请求，例如访问私有仓库。

一般情况下，PAT 以如下方式包含在请求头中：

通过这种方式发送 PAT，服务端就能验证你的身份、核查令牌权限，并决定是否返回数据或执行相应操作。

如何使用个人访问令牌？

生成个人访问令牌：先在你所用平台上新建 PAT，并选择具体的权限范围（scope）来决定其访问权限。
认证 API 请求：有了 PAT 后，用它来认证需要安全访问的服务。令牌要作为 bearer token 放入 API 请求的 authorization header 中。
撤销个人访问令牌：如需让某令牌失效，在平台认证设置中撤销即可。撤销后所有用此令牌的 API 请求都会自动被拒绝。

什么时候适合用个人访问令牌？

个人访问令牌适用于需要对 API 提供安全、友好、可控访问权限的场景。以下是一些典型应用案例：

自动化任务： 用于脚本或工具安全访问 API，无需为开发者嵌入敏感凭证。
细粒度权限控制： 允许通过脚本或工具只访问指定仓库等权限，而不暴露完整账号权限。
临时访问： 适用于安全敏感场景，可限制访问时长，降低风险。
简化开发者访问： 让开发者无需配置完整 OAuth 流程就能便捷获取访问权限。
第三方集成： 与外部工具结合时，只授权执行限定操作。例如，公司用项目管理工具时，第三方集成可以让团队成员直接在 Slack 聊天中创建任务或更新状态，而不用拥有项目管理工具的全部权限。

自 2013 年起，GitHub 率先推动 PAT 的普及，如今因其简单、灵活成为开发者首选。许多开发工具和 SaaS 平台均支持 PAT，易用性极高：