什么是 GitHub 应用？
本文介绍什么是 GitHub 应用、它们如何工作以及如何使用它们来改进工作流。 无论是采用其他人生成的解决方案，还是开发满足自己确切需求的解决方案，进程始终都有改进的空间。
通过 GitHub API 扩展平台
GitHub 提供了可靠的 API，使开发人员能够在平台上完成几乎任何操作。 它通过 REST 终结点公开，因此可与任何平台或编程语言轻松集成。 但 API 访问权限并不是独立存在的。 如果开发人员希望与他人共享其功能，仍需将其打包成应用并发布，别人才能使用它。
在考虑是将 OAuth 应用还是 GitHub应用合并到工作流中时，需要考虑多个因素。 在本部分中，我们将了解 GitHub 应用和 OAuth 应用、其使用情况和权限差异以及事件订阅。
自定义 GitHub 工作流时，可以使用多种功能，例如编写自定义脚本、创建和授权自己的 OAuth 应用，或安装 GitHub 市场中提供的 GitHub 应用。 通常，脚本最适用于一次性任务。 对于需要更频繁运行的操作，可以使用 OAuth 和 GitHub 应用的自动化来帮助你和团队节省时间，并保持工作流中的最佳安全级别。 存在许多差异会影响你决定是使用 GitHub 应用还是 OAuth 应用。 预先了解这些差异可以减少一些麻烦和返工，并帮助你找到适用于工作流中特定用例的最佳应用程序。
在本部分结束时，你可充分了解 GitHub 应用与 OAuth 应用之间的差异，以及如何根据适当的情况选择最适合的应用。
授权访问和授予权限
允许应用访问 GitHub 存储库时，要考虑的最重要的问题之一是操作所需的权限。 一些应用也许很容易受到信任，但另一些应用可能很可疑。 请确保你始终能够坦然接受自己授予应用的权限。
注意
每个应用都使用唯一的 API 密钥来请求存储库中的数据。 授予访问权限即向该密钥授予访问权限。 可以随时从存储库设置撤销对应用密钥的访问权限。
OAuth 应用
OAuth 应用提供了一种代表用户访问 GitHub 数据的方法。 由于它代表用户操作，因此必须注意，它将使用一个 GitHub 许可席位。 如果你有管理访问权限，则可以在个人帐户或组织级别创建并注册 OAuth 应用。 与 GitHub 集成的 OAuth 应用将公开所需的组织或存储库访问权限类型。 用户向 OAuth 应用授权，使应用能够以经过身份验证的用户身份执行操作，例如读取或修改数据。 此方法实质上是一种以用户身份自动读取、写入或编辑 GitHub 数据的方式。 还必须注意，授权仅限于用户可访问的资源，但是，OAuth 应用还可以访问用户可用的所有资源。
备注
访问级别受令牌的作用域（用户、组织、存储库）限制。
对于具有 OAuth 应用访问限制的组织，管理员可以批准使用应用程序。 借助事件订阅，OAuth 应用在活动发生时响应活动。
GitHub 应用
相比之下，GitHub 应用安装在个人帐户、你拥有的组织或你具有管理员访问权限的特定存储库中。 GitHub 应用以服务的形式安装并与 GitHub 交互，而不是像 OAuth 应用那样以单个用户的形式。 与 OAuth 应用不同，GitHub 应用的一个好处是 GitHub 应用不会占用 GitHub 许可席位。
GitHub 应用代表应用程序本身，通过用于对 JWT 令牌（JSON Web 令牌）进行签名的私钥访问数据。 由于它们安装在特定存储库中，因此用户可以选择应用能够访问哪些存储库，从而限制应用能够访问的数据量。 权限可定义 GitHub 应用可通过 API 访问的资源。 与 OAuth 应用不同，GitHub 应用具有对存储库数据、问题和拉取请求的可自定义权限。 这样，你可以授予更精细的权限，限制应用仅读取和写入已允许其访问的存储库。 只有组织所有者才能管理组织中 GitHub 应用的设置。
可以从 GitHub 市场中找到并安装 GitHub 应用。 在搜索 GitHub 应用时，请记住，某些应用具有已验证的徽章。 此徽章显示应用由已验证其域所有权、通过 GitHub 支持确认其电子邮件地址且要求其组织进行双重身份验证的组织拥有。
- 管理员可以授予有关存储库管理、检查、存储库内容、部署和问题的权限（管理员更改需要用户接受）
- 管理员可以向应用用户授予阻止其他用户、电子邮件、关注者、GPG 密钥、Git SSH 密钥、评定星级、观看的权限（管理员更改需要用户接受）
- 事件订阅：安全公告、检查套件、创建、部署、分叉、标签、成员、签入、提交注释、删除、部署状态、里程碑、成员身份、组织（管理员在 GH 应用 UI 中配置，并且可更改）
在 GitHub 应用和 OAuth 应用之间进行选择
尽管 GitHub 应用在某些情况下是集成到工作流的理想方法，但大型组织可能难以从使用 OAuth 应用实现自动化的传统做法过渡。 例如，安全策略限制也可能限制管理员选择使用这些工具的选项。
注意
作为系统管理员，你应该与开发人员合作，找到最适合的选项，从而可通过利用这些应用程序来实现自动化，同时保持遵循安全策略。
若要确定哪种应用适合你的情况，需要考虑以下一些重要问题：
- 是否希望应用充当用户？
- 需要怎样的速率限制？
- 我希望应用在组织和存储库中拥有哪些访问权限？
- 此应用是否符合我们的安全策略？
下面是在 GitHub 应用或 OAuth 应用之间进行选择时要考虑的一些主要特征和差异。
| GitHub 应用 | OAuth 应用 |
|---|---|
| 安装 GitHub 应用会授予应用对用户或组织帐户所选存储库的访问权限。 | 为 OAuth 应用授权会授予应用访问用户可访问资源的权限；例如，它们可以访问的存储库。 |
| 安装访问令牌仅限于具有应用创建者所选权限的指定存储库。 | OAuth 访问令牌通过作用域进行限制。 |
| 安装令牌将应用标识为 GitHub 应用机器人。 | 访问令牌将应用标识为向应用授予令牌的用户。 |
| GitHub 应用具有目标权限，使它们仅可请求所需内容的访问权限。 | OAuth 应用无法使用精细权限。 |
| GitHub 应用不受组织应用程序策略约束。 GitHub 应用仅有权访问组织所有者已授予的存储库。 | 如果组织应用程序策略处于活动状态，则只有组织所有者才能授权安装 OAuth 应用。 如果已安装，OAuth 应用可以访问组织所有者在批准的组织中拥有的令牌可见的任何内容。 |
| 可以在 GitHub 应用级别（影响所有安装）和单个安装级别授予速率限制增加。 | 针对每个 OAuth 应用授予速率限制增加。 授予该 OAuth 应用的每一个令牌都会获得增加的限制。 |
| GitHub 应用可以代表用户进行身份验证，这称为用户到服务器请求。 授权流与 OAuth 应用授权流相同。 用户到服务器令牌可能过期，可以使用刷新令牌进行续订。 | OAuth 应用使用的 OAuth 流代表用户授权 OAuth 应用。 这与 GitHub 应用用户到服务器授权中使用的流相同。 |
| GitHub 应用请求存储库内容权限，并使用安装令牌通过基于 HTTP 的 Git 进行身份验证。 | OAuth 应用请求 write:public_key 作用域，并通过 API 创建部署密钥。 然后，可以使用该密钥执行 Git 命令。 |
应用程序访问和权限
允许应用访问 GitHub 存储库时，要考虑的最重要的问题之一是操作所需的权限。 一些应用也许很容易受到信任，但另一些应用可能很可疑。 请确保你始终能够坦然接受自己授予应用的权限。
决定是使用 GitHub 应用还是 OAuth 应用可能取决于希望应用访问的访问级别。 通常，应该鼓励团队使用具有最小作用域的工具来完成任务。 OAuth 应用有权访问用户或组织所有者的所有资源。
- OAuth 应用可能具有 GitHub 数据的读取或写入访问权限
- 可以向 GitHub 应用授予对一个帐户的访问权限，而无需授予对另一个帐户的访问权限
应用程序安全性
在应用程序中发现漏洞时，应优先处理该漏洞，并在安全策略中告知项目的用户。 快速传达安全问题可能意味着用户能够撤销已泄露的令牌，避免公开敏感数据。 虽然令牌比密码安全得多，但安全性仍可能会受到影响，并且组织必须做好准备。
除 README.md 文件外，还建议将 SECURITY.md 文件添加到存储库。 此 SECURITY.md 强调了存储库的安全相关信息。 该文件应包括安全联系人、组织策略，并详细说明在发现漏洞时将做出的响应。
对事件作出响应
GitHub 应用的设计决定其是被动的。 它们会等待一些事件发生，然后（常通过 GitHub API）进行响应。 在等待 GitHub 上发生事件时，有两种方法：Webhook 和轮询。
备注
GitHub 应用并不仅限于处理 GitHub 数据。 你也可以同样轻松地等待由其他来源发生的事件，或者执行更新其他服务的操作。
使用 GitHub Webhook
Webhook 是处理事件的首选方法。 如果 GitHub 上发生某个 Webhook 范围内的事件，将立即引发该 Webhook。 Webhook 会推送通知，应用可以侦听并实时处理这些通知。 可以在存储库设置中配置 Webhook，包括事件类型、身份验证和 HTTP 通知的传递方式。
轮询
有时不能选择 Webhook。 应用可能需要在公司防火墙之后运行，GitHub 无法直接访问它。 在这种情况下，一种替代方法是使用 GitHub API 轮询正在跟踪的数据。
Webhook 中继
可以不轮询防火墙后面的应用，而使用 Webhook 转发服务，例如 smee.io。 使用此方法，公共服务将订阅存储库的 Webhook，然后将传入数据中继到在防火墙后面运行的客户端服务。 然后，客户端服务会将通知推送到正在运行的应用，就好像它们来自原始源一样。