改用 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 应用”。
全面持久授权
用户登录后，应用开发人员必须完成额外的步骤，以确保用户有权访问系统中的数据。 每次登录都需要对其成员身份、访问权限以及当前 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 字段跟踪用户标识之外，还应该保留每个用户所处的组织或企业的数据。 这将有助于确保在用户切换角色时不会泄露敏感信息。
例如：
- 用户处于需要 SAML SSO 的
Mona组织中，并在执行 SSO 后登录到你的应用。 你的应用现在可以访问用户在Mona中所做的任何操作。 - 用户从
Mona中的存储库中提取一堆代码，并将其保存在你的应用中进行分析。 - 稍后，用户切换作业，并从
Mona组织中删除。
当用户访问你的应用时，他们能否在其用户帐户中查看来自 Mona 组织的代码和分析？
这就是为什么跟踪应用保存的数据来源至关重要。 否则，你的应用对组织来说是一个数据保护威胁，如果他们不能相信你的应用正确地保护了其数据，他们很可能会禁止你的应用。
严重用户对应用的访问权限
组织或企业外部用户可以访问 OAuth 应用。 如果打算仅由组织或企业成员使用应用，则应在用户登录到应用时检查用户的会员资格状态。
要查找用户所属组织的列表，可以使用“列出已通过身份验证的用户的组织”终结点。 然后，可以根据应用的已获批准组织列表验证此列表。 有关详细信息，请参阅“适用于组织的 REST API 终结点”。
注意：**** 企业外部用户可访问 托管用户帐户 或 具有托管用户的组织 创建的 OAuth app。
保护应用的凭据
使用客户端密码，应用可以授权用户并生成用户访问令牌。 这些令牌用于代表用户发出 API 请求。
必须安全地存储应用的客户端密码和任何生成的令牌。 存储机制取决于集成体系结构及其运行平台。 通常，应使用旨在将敏感数据存储在所使用的平台上的存储机制。
客户端机密
如果应用是网站或 Web 应用，请考虑将客户端密码存储在密钥保管库（例如 Azure Key Vault）中，或者存储为服务器上的加密环境变量或机密。
如果你的应用是本机客户端、客户端应用，或者在用户设备上运行（而不是在服务器上运行），则无法保护客户端密码。 如果计划根据应用生成的令牌限制对自己服务的访问，应谨慎使用，因为任何人都可以访问客户端密码来生成令牌。
用户访问令牌
如果应用是网站或 Web 应用，则应在后端加密令牌，并确保可以访问令牌的系统的安全性。 请考虑将刷新令牌存储在与活动访问令牌不同的位置。
如果你的应用是本机客户端、客户端应用或在用户设备上运行（而不是在服务器上运行），则可能无法保护令牌以及在服务器上运行的应用。 应通过为应用平台推荐的机制来存储令牌，请记住，存储机制可能并不完全安全。
使用合适的令牌类型
OAuth apps 可以生成用户访问令牌来发出经过身份验证的 API 请求。 在任何情况下，应用都不应使用 personal access token 或 GitHub 密码进行身份验证。
制定处理安全漏洞的计划
应制定计划，以便及时处理任何安全漏洞。
如果应用的客户端密码遭到入侵，则需要生成新的密码，更新应用以使用新密码，并删除旧密码。
如果安用户访问令牌遭到入侵，应立即撤销这些令牌。 有关详细信息，请参阅“用于 OAuth 授权的 REST API 终结点”。
定期进行漏洞扫描
应定期对应用进行漏洞扫描。 例如，可以为托管应用代码的存储库设置代码扫描和机密扫描。 有关详细信息，请参阅“关于代码扫描”和“关于机密扫描”。
选择适当的环境
如果应用在服务器上运行，请验证服务器环境是否安全，以及它是否能够处理应用预期的流量。
以安全的方式使用服务
如果应用使用第三方服务，则应以安全的方式使用它们：
- 应用使用的任何服务都应具有唯一的登录名和密码。
- 应用程序不应共享服务帐户（如电子邮件或数据库服务）来管理 SaaS 服务。
- 只有履行管理职责的员工才应具有托管应用的基础结构的管理员访问权限。
添加日志记录和监视
请考虑为应用添加日志记录和监视功能。 安全日志可以包括：
- 身份验证和授权事件
- 服务配置更改
- 对象读取和写入
- 用户和组权限更改
- 角色提升到管理员
日志应为每个事件使用一致的时间戳，并应记录所有记录事件的用户、IP 地址或主机名。
启用数据删除
如果应用可供其他用户使用，则应为用户提供删除其数据的方法。 用户应无需发送电子邮件或致电支持人员即可删除其数据。