改用 GitHub App
如果可以，请考虑使用 GitHub App 而不是 OAuth app。 一般来说，GitHub Apps 优先于 OAuth apps。 GitHub Apps 使用精细权限，让用户更好地控制应用可以访问的存储库，并使用生存期较短的令牌。 这些属性可以限制在应用的凭据泄露时可能造成的损害，从而强化应用的安全性。
与 OAuth apps 类似，GitHub Apps 仍可使用 OAuth 2.0 并生成一种类型的 OAuth 令牌（称为用户访问令牌）并代表用户执行操作。 但是，GitHub Apps 也可以独立于用户进行操作。
若要详细了解 GitHub Apps，请参阅“关于创建 GitHub 应用”。
有关将现有 OAuth app 迁移到 GitHub App 的详细信息，请参阅“将 OAuth 应用迁移到 GitHub 应用”。
使用最小范围
OAuth app 应仅请求应用执行其预期功能所需的范围。 如果应用的任何令牌遭到入侵，这将限制可能造成的破坏程度。 有关详细信息，请参阅“授权 OAuth 应用”。
保护应用的凭据
使用客户端密码，应用可以授权用户并生成用户访问令牌。 这些令牌用于代表用户发出 API 请求。
必须安全地存储应用的客户端密码和任何生成的令牌。 存储机制取决于集成体系结构及其运行平台。 通常，应使用旨在将敏感数据存储在所使用的平台上的存储机制。
客户端机密
如果应用是网站或 Web 应用，请考虑将客户端密码存储在密钥保管库（例如 Azure Key Vault）中，或者存储为服务器上的加密环境变量或机密。
如果你的应用是本机客户端、客户端应用，或者在用户设备上运行（而不是在服务器上运行），则无法保护客户端密码。 如果计划根据应用生成的令牌限制对自己服务的访问，应谨慎使用，因为任何人都可以访问客户端密码来生成令牌。
用户访问令牌
如果应用是网站或 Web 应用，则应在后端加密令牌，并确保可以访问令牌的系统的安全性。 请考虑将刷新令牌存储在与活动访问令牌不同的位置。
如果你的应用是本机客户端、客户端应用或在用户设备上运行（而不是在服务器上运行），则可能无法保护令牌以及在服务器上运行的应用。 应通过为应用平台推荐的机制来存储令牌，请记住，存储机制可能并不完全安全。
使用合适的令牌类型
OAuth apps 可以生成用户访问令牌来发出经过身份验证的 API 请求。 在任何情况下，应用都不应使用 personal access token 或 GitHub 密码进行身份验证。
制定处理安全漏洞的计划
应制定计划，以便及时处理任何安全漏洞。
如果应用的客户端密码遭到入侵，则需要生成新的密码，更新应用以使用新密码，并删除旧密码。
如果安用户访问令牌遭到入侵，应立即撤销这些令牌。 有关详细信息，请参阅“用于 OAuth 授权的 REST API 终结点”。
管理用户对组织的访问
组织或企业外部用户可以访问 OAuth 应用。 如果打算仅由组织或企业成员使用应用，则应在用户登录到应用时检查用户的会员资格状态。
要查找用户所属组织的列表，可以使用“列出已通过身份验证的用户的组织”终结点。 然后，可以根据应用的已获批准组织列表验证此列表。 有关详细信息，请参阅“适用于组织的 REST API 终结点”。
定期进行漏洞扫描
应定期对应用进行漏洞扫描。 例如，可以为托管应用代码的存储库设置代码扫描和机密扫描。 有关详细信息，请参阅“关于代码扫描”和“关于机密扫描”。
选择适当的环境
如果应用在服务器上运行，请验证服务器环境是否安全，以及它是否能够处理应用预期的流量。
以安全的方式使用服务
如果应用使用第三方服务，则应以安全的方式使用它们：
- 应用使用的任何服务都应具有唯一的登录名和密码。
- 应用程序不应共享服务帐户（如电子邮件或数据库服务）来管理 SaaS 服务。
- 只有履行管理职责的员工才应具有托管应用的基础结构的管理员访问权限。
添加日志记录和监视
请考虑为应用添加日志记录和监视功能。 安全日志可以包括：
- 身份验证和授权事件
- 服务配置更改
- 对象读取和写入
- 用户和组权限更改
- 角色提升到管理员
日志应为每个事件使用一致的时间戳，并应记录所有记录事件的用户、IP 地址或主机名。
启用数据删除
如果应用可供其他用户使用，则应为用户提供删除其数据的方法。 用户应无需发送电子邮件或致电支持人员即可删除其数据。