本页面介绍了一些与 OAuth 2.0 集成的常规最佳做法。除了适用于您的应用和开发平台类型的任何具体指南之外，请考虑这些最佳实践。另请参阅有关准备好正式版应用的建议和 Google 的 OAuth 2.0 政策。
安全地处理客户端凭据
OAuth 客户端凭据用于标识应用的身份，因此应谨慎处理。请仅将这些凭据存储在安全的存储空间中，例如使用 Google Cloud Secret Manager 等 Secret Manager。 请勿对凭据进行硬编码，也不要将其提交到代码库或公开发布。
安全地处理用户令牌
用户令牌包括应用使用的刷新令牌和访问令牌。令牌以静态安全存储，切勿以明文形式传输。使用适合您平台的安全存储系统，例如 Android 上的Keystore、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 开发者控制台明确确认服务条款、配置 OAuth 客户端并准备好进行 OAuth 验证。
对于自动化工作流，请考虑改用服务账号。