确定支持的访问令牌

8 分钟

本部分介绍不同的 GitHub 访问令牌、其应用程序、限制和速率限制。

在向公司中的用户授予访问权限时，身份验证非常重要。用户访问权限应具有严格的作用域，并且只包括用户完成任务所需的内容。了解不同的访问令牌非常重要，因为这有助于指导公司中的用户使用最适合其用例的选项。

GitHub 使用多种令牌，这些令牌允许用户对需要执行的不同活动进行身份验证。通常，这些不同的令牌简单明了，并且很容易知道要使用什么令牌。但有时，可以使用多个令牌来实现相同的结果，因此，选择某个令牌最终与决策的好坏程度相关。在这些情况下，必须确定 GitHub 令牌的特征以及如何正确确定令牌的访问作用域。下面是可用的不同访问令牌的列表：

GitHub 个人访问令牌
GitHub 用户到服务器令牌
GitHub 服务器到服务器令牌
OAuth 访问令牌
刷新令牌

必须鼓励开发团队使用具有正确作用域的令牌，以便在发现安全漏洞时可以快速缓解风险。让我们进一步了解其中每个访问令牌。

个人访问令牌

个人访问令牌 (PAT) 是使用密码对 GitHub 进行身份验证的替代方法。若要在存储库中进行推送和拉取，GitHub 需要验证用户访问权限。验证通过用户经过验证的电子邮件地址完成。你可以根据工作流的要求创建任意数量的个人访问令牌，并且应该像对待密码一样安全地对待它们。对不同的应用程序使用不同的令牌是最佳安全做法。若要在 GitHub 中创建个人访问令牌，请导航到“设置”，在“开发人员设置”下找到“个人访问令牌”。

Screenshot with an example of a GitHub personal access token.

可以将单个令牌的作用域仅限于对向其分配的作业进行身份验证所需的访问权限。令牌绑定到特定用户，并与用户对组织和存储库的访问权限保持一致。可以随时撤销个人访问令牌，这在发生安全黑客攻击时尤其重要。请务必告知团队，应像对待用户名和密码一样安全地对待其个人访问令牌。如果令牌确实遭到入侵，应立即采取措施来撤销令牌。

此处提供了创建个人访问令牌的详细步骤：创建个人访问令牌 - GitHub Docs

设备令牌

设备令牌基本上就是 PAT 的计算机帐户版本，在设备上下文中使用，在非用户绑定的特定用例中提供对特定存储库的访问权限。使用 OAuth 流的应用程序设置会使用设备令牌。它们通常用于运行程序、特殊应用程序服务、Cron 作业（Linux 中）或与自动化任务相关的其他类似方案。就像个人访问令牌一样，它绑定到个人帐户，你为其创建了设备令牌的帐户会使用一个许可证。

GitHub 应用程序安装令牌

安装令牌允许 GitHub 应用针对在组织中安装应用程序提出经过身份验证的 API 请求。在创建安装令牌之前，需要在目标存储库中安装令牌将应用到的 GitHub 应用。安装令牌的有效期为 1 小时，因为它们是出于特定目的生成的，并且会在相对短的时间内过期，因此是安全的。

OAuth 访问令牌

OAuth2 令牌用于授权用户使用在浏览器中运行的标准 OAuth 应用以及无外设应用（例如 CLI 工具）。它们允许应用使用用户访问令牌访问 API。使用这些令牌，你可以将 GitHub 用户标识连接到第三方应用程序，从而允许应用代表你执行操作。例如，如果要使用请求 user:email 作用域的应用，该应用将具有对专用电子邮件地址的只读访问权限。可以使用用于生产应用程序的 Web 应用程序流来获取这些令牌。因为这些令牌是短期的，在 10 分钟后过期，所以它们也是安全的。

刷新令牌

刷新令牌与 OAuth 令牌连接。授予新的 OAuth 令牌（通过用户到服务器请求）时，响应中会包含刷新令牌。用户令牌即将到期时，可以通过回调请求将刷新令牌交换为新的用户令牌。每次颁发新的 OAuth 令牌时，都会包含刷新令牌。刷新令牌的有效期为六个月，是更新 OAuth 令牌的一个好提醒。

可识别前缀

正如我们在整个行业中所看到的，令牌前缀是一种使令牌可识别的明确方法。 GitHub 包含三个字母前缀来表示每个令牌，以公司表示符 gh 开头，后接令牌类型的第一个字母。上述令牌类型的结果为：

ghp 表示 GitHub 个人访问令牌
ghu 表示 GitHub 用户到服务器令牌
ghs 表示 GitHub 服务器到服务器令牌
gho 表示 OAuth 访问令牌
ghr 表示刷新令牌

此外，这些前缀在令牌中具有分隔符 (_)，以提高可读性。下划线不是 Base64 字符，有助于确保随机生成的字符串（如 SHA）不会意外复制这些令牌。这些前缀还有助于降低机密扫描的误报率，这是一项 GitHub 高级安全功能，可进一步提高 GitHub 存储库的安全性。

令牌速率限制

超过速率限制可能会导致损失开发时间。我们来讨论一下 GitHub 应用和 OAuth 应用的速率限制。通过了解速率限制，你可以成为团队开发人员的资源，帮助优化组织对这些 GitHub 资源的投资。

速率限制基于每小时的请求数，有助于控制 GitHub 上的流量速率。

安装在 GitHub 企业帐户上的 GitHub 应用的请求速率限制为每小时 15,000 个请求。
OAuth 应用对单个用户进行身份验证，限制为每小时 5,000 个请求。

对于企业管理员，你应该监视应用速率限制，并与开发人员一起调整其脚本，以保持在限制范围内。通常，在开发人员执行某些操作（例如编写在工作流中请求过多信息的脚本）之前，速率限制不是问题。开发突然停止，速率限制成为瓶颈。通过限制每小时的请求数或更改工作流以在请求之间等待一段时间，可以避免这些超出速率限制的问题。如果使用基本身份验证或 OAuth 时超出了速率限制，则可以通过缓存 API 响应和使用条件请求来解决此问题。

在管理控制台中，你可以为企业中未经身份验证的用户设置自定义速率限制，并创建允许某些用户使用完整 API 速率限制的豁免列表。

Screenshot of the management console setting the API rate limits.

可以使用以下速率限制 API 随时检查当前速率限制状态。任何 API 请求的返回 HTTP 标头都会显示当前速率限制状态。

curl \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/rate_limit

示例响应

{
  "resources": {
    "core": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1372700873,
      "used": 1
    },
    "search": {
      "limit": 30,
      "remaining": 18,
      "reset": 1372697452,
      "used": 12
    },
    "graphql": {
      "limit": 5000,
      "remaining": 4993,
      "reset": 1372700389,
      "used": 7
    },
    "integration_manifest": {
      "limit": 5000,
      "remaining": 4999,
      "reset": 1551806725,
      "used": 1
    },
    "code_scanning_upload": {
      "limit": 500,
      "remaining": 499,
      "reset": 1551806725,
      "used": 1
    }
  },
  "rate": {
    "limit": 5000,
    "remaining": 4999,
    "reset": 1372700873,
    "used": 1
  }
}

有关速率限制的更多详细信息，请参阅 GitHub Docs 上的速率限制。