本页面介绍了与 OAuth 2.0 集成的一些常规最佳实践。除了针对您的应用和开发平台类型的任何具体指南之外，请考虑这些最佳实践。另请参阅使应用做好正式发布准备的建议和 Google 的 OAuth 2.0 政策。
安全地处理客户端凭据
OAuth 客户端凭据用于标识您的应用的身份，应谨慎处理。请仅将这些凭据存储在安全存储空间中，例如使用 Google Cloud Secret Manager 等 Secret Manager。请勿对凭据进行硬编码，也不要将凭据提交到代码库或公开发布。
安全地处理用户令牌
用户令牌包括应用使用的刷新令牌和访问令牌。以安全的方式存储令牌，绝不以明文形式传输。使用适合您平台的安全存储系统，例如 Android 上的密钥库、iOS 和 macOS 上的钥匙串服务或 Windows 上的 Credential Locker。
尽快撤消不再需要的令牌，并将其从您的系统中永久删除。
此外，您还应考虑以下适用于您的平台的最佳做法：
- 对于为许多用户存储令牌的服务器端应用，请对令牌进行静态加密，并确保互联网无法公开访问您的数据存储区。
- 对于原生桌面应用，强烈建议使用用于代码交换的证明密钥 (PKCE) 协议获取可用于交换访问令牌的授权代码。
处理刷新令牌的撤消和到期
如果您的应用已请求用于离线访问的刷新令牌，您还必须处理其失效或过期问题。令牌可能因各种原因而失效，例如令牌可能已过期，或者您的应用的访问权限可能已被用户或自动化流程撤消。在这种情况下，请仔细考虑您的应用应如何响应，包括在用户下次登录时提示用户或者清理其数据。如需收到令牌撤消的通知，请与跨帐号保护服务集成。
使用增量授权
如果您的应用需要功能，请使用增量授权来请求适当的 OAuth 范围。
您不应在用户首次进行身份验证时请求访问数据，除非这对实现应用的核心功能至关重要。相反，请仅请求执行任务所需的特定范围，并遵循尽可能选择最小、最大受限范围的原则。
请始终根据上下文请求范围，帮助用户了解应用请求访问权限的原因以及数据的使用方式。
例如，您的应用可能遵循以下模型：
- 用户使用您的应用进行身份验证
- 无需请求额外的范围。应用提供基本功能，可让用户探索和使用不需要任何额外数据或访问权限的功能。
- 用户选择需要访问额外数据的某项功能
- 您的应用针对此功能所需的这一特定 OAuth 范围发出授权请求。如果此功能需要多个范围，请遵循以下最佳实践。
- 如果用户拒绝请求，应用会停用此功能，并为用户提供再次请求访问权限的其他上下文。
处理多个范围的用户意见征求
在一次请求多个范围时，用户可能不会授予您已请求的所有 OAuth 范围。您的应用应通过停用相关功能来处理拒绝作用域请求。
如果应用的基本功能需要多个范围，请在提示用户同意之前向用户说明这一点。
只有当用户明确表示有意使用需要该范围的特定功能时，您才能再次提示用户。在请求 OAuth 范围之前，您的应用应为用户提供相关上下文和理由。
您应尽量减少应用一次请求的范围数。您可以通过增量授权来请求特定特性和功能的范围。
使用安全浏览器
在网络上，OAuth 2.0 授权请求只能通过功能齐全的网络浏览器发出。在其他平台上，请务必选择正确的 OAuth 客户端类型，并根据您的平台情况集成 OAuth。请勿通过嵌入式浏览环境（包括移动平台上的 WebView，例如 Android 上的 WebView 或 iOS 上的 WKWebView）来重定向请求。而是为您的平台使用原生 OAuth 库或 Google 登录功能。
手动创建和配置 OAuth 客户端
为防止滥用情况的发生，您无法以程序化方式创建或修改 OAuth 客户端。您必须使用 Google Developers Console 明确确认服务条款，配置 OAuth 客户端，并准备进行 OAuth 验证。
对于自动化工作流，请考虑改用服务帐号。