改用 GitHub App
如果可能，请考虑使用 GitHub App 而不是 OAuth App。通常，GitHub App 比 OAuth App 更受欢迎。GitHub App 使用细粒度的权限，使用户能够更好地控制 App 可以访问哪些仓库，并使用短期令牌。这些特性可以通过限制在 App 凭据泄露时可能造成的损害来增强 App 的安全性。
与 OAuth App 类似，GitHub App 仍然可以使用 OAuth 2.0 并生成一种 OAuth 令牌（称为用户访问令牌）并代表用户执行操作。但是，GitHub App 也可以独立于用户执行操作。
有关 GitHub App 的更多信息，请参阅“关于创建 GitHub App”。
有关将现有 OAuth App 迁移到 GitHub App 的更多信息，请参阅“将 OAuth App 迁移到 GitHub App”。
使用最小范围
您的 OAuth App 应该只请求 App 执行其预期功能所需的范围。如果 App 的任何令牌遭到泄露，这将限制可能发生的损害。有关更多信息，请参阅“授权 OAuth App”。
彻底且持久地授权
用户登录后，App 开发人员必须采取其他步骤来确保用户有权访问系统中的数据。每次登录都需要围绕其成员资格、访问权限和当前 SSO 状态进行新的检查。
使用持久且唯一的 id 来存储用户
当用户登录并在您的应用程序中执行操作时，您必须记住哪个用户执行了该操作，以便在下一次他们登录时授予他们访问相同资源的权限。
要正确地将用户存储在数据库中，请始终使用用户的 id。此值永远不会更改用户或用于指向不同的用户，因此它确保您正在向您打算的用户提供访问权限。您可以使用 GET /user REST API 端点找到用户的 id。请参阅“用户的 REST API 端点”。
如果存储对仓库、组织和企业的引用，也请使用它们的 id 以确保您对它们的链接保持准确。
切勿使用可能随时间变化的标识符，包括用户句柄、组织别名或电子邮件地址。
验证每次新的身份验证的组织访问权限
当您使用用户访问令牌时，您应该跟踪该令牌被授权用于哪些组织。如果某个组织使用 SAML SSO 且用户未执行 SAML SSO，则用户访问令牌将无法访问该组织。您可以使用 GET /user/installations REST API 端点来验证用户访问令牌可以访问哪些组织。如果用户无权访问某个组织，则应阻止他们访问组织拥有的数据，直到他们执行 SAML SSO 为止。有关更多信息，请参阅“GitHub App 安装的 REST API 端点”。
使用组织和企业上下文存储用户数据
除了通过 id 字段跟踪用户身份之外，您还应该保留每个用户在其下操作的组织或企业的相关数据。这将有助于确保如果用户切换角色，不会泄露敏感信息。
例如
- 某个用户位于
Mona组织中，该组织需要 SAML SSO，并在执行 SSO 后登录到您的 App。您的 App 现在可以访问用户在Mona中执行的所有操作。 - 用户从
Mona中的某个仓库中提取大量代码并将其保存在您的 App 中进行分析。 - 稍后，用户换了工作，并从
Mona组织中移除。
当用户访问您的 App 时，他们是否仍然可以在其用户帐户中看到来自 Mona 组织的代码和分析？
这就是为什么跟踪您的 App 正在保存的数据来源至关重要的原因。否则，您的 App 将成为组织的数据保护威胁，如果他们无法信任您的 App 正确保护其数据，他们可能会禁止您的 App。
验证用户对 App 的访问权限
您的 OAuth App 可以被组织或企业外部的用户访问。如果您打算仅允许组织或企业成员使用 App，则应在用户登录到 App 时检查用户的成员资格状态。
要查找用户所属的组织列表，您可以使用“列出已认证用户的组织”端点。然后，您可以根据 App 的已批准组织列表验证此列表。有关更多信息，请参阅“组织的 REST API 端点”。
保护 App 的凭据
使用客户端密钥，您的 App 可以授权用户并生成用户访问令牌。这些令牌可用于代表用户发出 API 请求。
您必须安全地存储 App 的客户端密钥和任何生成的令牌。存储机制取决于您的集成架构及其运行的平台。通常，您应该使用旨在在您使用的平台上存储敏感数据的存储机制。
客户端密钥
如果您的 App 是网站或 Web App，请考虑将您的客户端密钥存储在密钥保管库中，例如 Azure Key Vault，或作为服务器上的加密环境变量或密钥。
如果您的 App 是本机客户端、客户端 App 或在用户设备上运行（而不是在您的服务器上运行），则无法保护您的客户端密钥。如果您计划根据 App 生成的令牌来控制对您自己服务的访问，则应谨慎行事，因为任何人都可以访问客户端密钥来生成令牌。
用户访问令牌
如果您的 App 是网站或 Web App，则应在后端加密令牌，并确保可以访问令牌的系统具有安全性。请考虑将刷新令牌存储在与活动访问令牌不同的位置。
如果您的 App 是本机客户端、客户端 App 或在用户设备上运行（而不是在您的服务器上运行），则您可能无法像在服务器上运行的 App 那样安全地存储令牌。您应该通过 App 平台推荐的机制存储令牌，并记住存储机制可能并非完全安全。
使用合适的令牌类型
OAuth App 可以生成用户访问令牌以进行身份验证的 API 请求。您的 App 绝不应使用个人访问令牌或 GitHub 密码进行身份验证。
制定处理安全漏洞的计划
您应该制定一个计划，以便能够及时处理任何安全漏洞。
如果 App 的客户端密钥遭到泄露，您需要生成一个新的密钥，更新您的 App 以使用新密钥，并删除旧密钥。
如果用户访问令牌遭到泄露，您应该立即撤销这些令牌。有关更多信息，请参阅“OAuth 授权的 REST API 端点”。
定期进行漏洞扫描
您应该定期对 App 进行漏洞扫描。例如，您可以为托管 App 代码的仓库设置代码扫描和密钥扫描。有关更多信息，请参阅“关于代码扫描”和“关于密钥扫描”。
选择合适的环境
如果您的 App 在服务器上运行，请验证您的服务器环境是否安全，并且它能够处理您期望 App 的流量。
以安全的方式使用服务
如果您的 App 使用第三方服务，则应以安全的方式使用它们。
- App 使用的任何服务都应具有唯一的登录名和密码。
- App 不应共享服务帐户（如电子邮件或数据库服务）来管理您的 SaaS 服务。
- 只有具有管理职责的员工才能访问托管 App 的基础设施。
添加日志记录和监控
考虑为您的 App 添加日志记录和监控功能。安全日志可能包括：
- 身份验证和授权事件
- 服务配置更改
- 对象读写
- 用户和组权限更改
- 角色提升到管理员
您的日志应为每个事件使用一致的时间戳，并应记录所有已记录事件的用户、IP 地址或主机名。
启用数据删除
如果您的 App 可供其他用户使用，则您应该为用户提供一种删除其数据的方法。用户不应需要发送电子邮件或致电支持人员才能删除其数据。