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