Skip to main content

决定何时生成GitHub应用

构建集成时,在以下场景中,您应考虑使用 GitHub App,而不是 OAuth app、personal access token 或 GitHub Actions。

使用GitHub App而不是OAuth app

一般情况下, GitHub Apps 首选于 OAuth apps.

OAuth apps 和 GitHub Apps 均使用 OAuth 2.0。

OAuth apps 只能代表用户执行操作,而 GitHub Apps 只能代表用户或独立于用户执行操作。

有关详细信息,请参阅“GitHub 应用和 OAuth 应用之间的差异”。

有关如何将现有项 OAuth app 迁移到 a GitHub App的信息,请参阅 将 OAuth 应用迁移到 GitHub 应用

GitHub Apps 提供增强的安全性

GitHub Apps 提供对应用可以执行的操作的更多控制。 OAuth apps 使用细粒度权限,而不是 GitHub Apps 使用的宽泛作用域。 例如,如果你的应用需要读取存储库的内容,则需要 OAuth app 范围 repo ,这也会让应用编辑存储库内容和设置。 A GitHub App 可以请求对存储库内容的只读访问权限,这不会让应用执行更多特权操作,例如编辑存储库内容或设置。

GitHub Apps 还提供对存储库访问的更多控制。 GitHub App安装应用的用户或组织所有者可以决定应用可以访问哪些存储库。 相反,OAuth app 可以访问授权该应用的用户能够访问的每个仓库。

GitHub Apps 使用生存期较短的令牌。 如果令牌泄漏,令牌的有效期将缩短,这样可以降低可能造成的损害。 相反, OAuth app 在授权 OAuth app 令牌的人吊销令牌之前,令牌不会过期。

这些安全功能通过限制应用凭据泄露时可能造成的损害来增强 GitHub App安全性。 此外,安全策略更严格的组织也由此可以使用你的应用。

GitHub Apps 可以独立于用户行动,也可以代表用户行动

GitHub Apps 可以独立于用户执行操作。 这有利于不需要用户输入的自动化。

类似于 OAuth apps, GitHub Apps 仍可以代表用户执行操作。 与 OAuth apps不指示应用执行的操作不同, GitHub Apps 指示该操作由应用代表用户执行。

GitHub Apps 不会关联到用户账户,也不会占用 许可证。 GitHub Apps 即使最初安装应用的人员离开组织,也会保持安装状态。 因此,即使有人离开团队,集成也能继续正常工作。

GitHub Apps 具有可扩展的速率限制

使用安装访问令牌时,GitHub Apps 的速率限制会随着仓库数量和组织用户数量而变化。 相反, OAuth apps 具有较低的速率限制,并且不缩放。 有关详细信息,请参阅“GitHub 应用的速率限制”。

GitHub Apps 具有内置的 Webhook

GitHub Apps 具有内置的集中式 Webhook。 GitHub Apps 可以接收应用可以访问的所有存储库和组织的 Webhook 事件。 相反, OAuth apps 必须为每个存储库和组织单独配置 Webhook。

API 的访问方式略有不同

一般情况下,GitHub Apps 和 OAuth apps 可以发起相同的 API 请求。 但是,两者存在一些差异:

  • 用于管理检查运行和检查套件的 REST API 仅适用于 GitHub Apps。
  • 企业对象本身等企业级资源不可用 GitHub Apps。 这意味着 GitHub Apps 无法调用终结点,例如 GET /enterprise/settings/license。 但是,企业拥有的组织和存储库资源可用。
  • 某些请求可能会返回不完整的数据,这取决于授予给 GitHub App 的权限和仓库访问权限。 例如,如果应用发出获取用户可以访问的所有存储库的请求,则响应将仅包括应用也有权访问的存储库。

有关可供使用的 GitHub AppsREST API 终结点的详细信息,请参阅 适用于 GitHub Apps 安装访问令牌的终结点

选择 GitHub App 还是 personal access token

如果您想要代表某个用户访问 GitHub 资源,或在组织内访问这些资源,或者预期进行长期集成,我们建议构建一个 GitHub App。

你可以使用 personal access tokens 进行 API 测试或运行短期脚本。 由于 personal access token 与某个用户关联,因此如果该用户不再有权访问您所需的资源,您的自动化流程可能会失效。 安装在组织上的GitHub App并不依赖于用户。 此外,与用户不同,一个GitHub App不占用GitHub许可证。

GitHub 支持两种类型的 personal access tokens,但建议尽可能使用 fine-grained personal access token,而不是 personal access tokens (classic)。 有关 personal access tokens 的详细信息,请参阅 管理个人访问令牌

选择GitHub App还是GitHub Actions

GitHub Apps 和 GitHub Actions 都提供了构建自动化和工作流工具的方式。

_ GitHub Actions _ 提供自动化,可在存储库中执行持续集成、部署任务和项目管理等作业。 它们直接在由 GitHub 托管的运行器机器上运行,或直接在由管理员设置的自托管运行器上运行。 GitHub Actions 请勿持续运行。 GitHub Actions 工作流在响应其存储库中发生的事件时运行,并且只能访问为其设置的存储库的资源。 但是,可以在存储库和组织之间共享自定义操作,使开发人员能够重复使用和修改现有操作来满足其需求。 GitHub Actions 还附带了内置的机密管理,可用于安全地与第三方服务交互,并安全地管理部署密钥。

_ GitHub Apps _ 在由你提供的服务器或计算基础设施上持续运行,或在用户设备上运行。 它们可以对 GitHub Webhook 事件以及生态系统外部 GitHub 的事件做出反应。 该应用适用于跨多个存储库或组织的操作或者为其他组织和企业提供托管服务。 当构建一种工具,而其功能主要发生在 GitHub App 之外,或需要的执行时间或权限超过 GitHub 工作流所分配的范围时,GitHub Actions 是最佳选择。

有关比较GitHub ActionsGitHub Apps的详细信息,请参阅 GitHub Actions 与 GitHub 应用

您可以在 GitHub App 中使用GitHub Actions进行身份验证。 当内置的 GITHUB_TOKEN 没有足够权限时的工作流 有关详细信息,请参阅“在GitHub Actions工作流中使用GitHub应用发出经过身份验证的 API 请求”。