本指南介绍了如何确保应用和用户凭据的安全。
完成 OAuth 应用验证
Google Ads API 的 OAuth 2.0 范围被归类为受限范围，这意味着您应先完成 OAuth 应用验证流程，然后再将应用投入生产。如需了解详情，请参阅 Google Identity 文档、关于未经验证的应用的帮助中心文章以及设置 OAuth 权限请求页面的相关文档。
保护应用凭证
您应保护应用的 OAuth 2.0 客户端 ID 和客户端密钥。 这些凭据可帮助您的用户和 Google 识别您的应用，因此应谨慎处理。您应像对待密码一样对待这些应用凭证。请勿使用不安全的机制共享这些凭证，例如在公共论坛上发布、在电子邮件附件中发送包含这些凭证的配置文件、对凭证进行硬编码或将其提交到代码库。我们建议您尽可能使用 Secret Manager，例如 Google Cloud Secret Manager 或 AWS Secrets Manager。
如果您的 OAuth 2.0 客户端密钥遭到泄露，您可以重置密钥。
保护服务账号
如果您使用服务账号，请按以下方式保护它们：
请将服务账号密钥和 JSON 文件视为密码。请尽可能使用 Google Cloud Secret Manager 或 AWS Secrets Manager 等 Secret Manager 来保护这些凭据。
遵循 Google Cloud 的其他最佳实践，确保服务账号的安全并对其进行管理。
保护用户令牌
如果您的应用向多位用户授权，您应采取额外措施来保护用户的刷新令牌和访问令牌。安全地存储静态令牌，切勿以纯文本形式传输令牌。使用适合您平台的安全存储系统。
处理刷新令牌撤消和过期
如果您的应用在授权过程中请求 OAuth 2.0 刷新令牌，您还必须处理其失效或过期问题。刷新令牌可能会因各种原因而失效，您的应用应在用户下次登录会话期间重新授权用户，或酌情清理其数据，从而做出妥善响应。离线作业（例如 cron 作业）应检测并记录刷新令牌已过期的账号，而不是继续发出失败的请求。Google 可能会限制在一段时间内持续产生大量错误的应用，以维持 API 服务器的稳定性。
管理多个范围的同意情况
如果您的应用请求多个 OAuth 2.0 范围的授权，用户可能不会授予您请求的所有 OAuth 范围。您的应用应通过停用相关功能来处理范围遭拒的情况。只有在用户明确表示有意使用需要该范围的特定功能后，您才能再次提示用户。在这种情况下，请使用增量授权请求适当的 OAuth 范围。
如果应用的基本功能需要多个范围，请在提示用户同意之前向用户说明此要求。