最佳实践

安全地处理客户端凭据

OAuth 客户端凭据用于标识应用的身份，应妥善处理。仅将这些凭据存储在安全存储空间中，例如使用 Google Cloud Secret Manager 等 Secret 管理器。 请勿对凭据进行硬编码、将其提交到代码库或公开发布。

安全地处理用户令牌

用户令牌包括您的应用使用的刷新令牌和访问令牌。安全地存储静态令牌，并且绝不以纯文本形式传输令牌。使用适合您平台的安全存储系统，例如 Android 上的 Keystore、iOS 和 macOS 上的密钥链服务，或 Windows 上的凭据保险箱。

在不再需要令牌时，立即撤消令牌，并从您的系统中永久删除令牌。

此外，还请考虑以下平台最佳实践：

• 对于存储许多用户令牌的服务器端应用，请对令牌进行静态加密，并确保您的数据存储区无法通过公开的网络访问。
• 对于原生桌面应用，强烈建议使用用于代码交换的证明密钥 (PKCE) 协议来获取可交换为访问令牌的授权代码。

处理刷新令牌撤消和过期

如果您的应用已请求用于离线访问的刷新令牌，您还必须处理其失效或过期情况。令牌可能会因各种原因而失效，例如令牌可能已过期，或者用户或自动化流程可能已撤消应用的访问权限。在这种情况下，请仔细考虑您的应用应如何响应，包括在用户下次登录时提示用户或清理用户的数据。如需在令牌被撤消时收到通知，请与跨账号保护服务集成。

使用增量授权

使用增量授权在应用需要相应功能时请求适当的 OAuth 范围。

除非对应用的核心功能至关重要，否则您不应在用户首次进行身份验证时请求访问数据。相反，您应仅请求任务所需的特定范围，并遵循尽可能选择最小、最有限的范围的原则。

始终在用户执行相关操作时请求范围，以帮助用户了解您的应用为何请求访问权限以及数据将如何使用。

例如，您的应用可以遵循以下模型：

1. 用户向您的应用进行身份验证
   1. 未请求任何其他范围。该应用提供基本功能，让用户探索和使用不需要任何额外数据或访问权限的功能。
2. 用户选择需要访问其他数据的功能
   1. 您的应用会针对此功能所需的特定 OAuth 范围发出授权请求。如果此功能需要多个范围，请遵循以下最佳实践。
   2. 如果用户拒绝该请求，应用会停用相应功能，并向用户提供更多背景信息，以便用户再次请求访问权限。

处理针对多个范围的用户意见征求

当您同时请求多个范围时，用户可能不会授予您请求的所有 OAuth 范围。应用应通过停用相关功能来处理范围遭拒的情况。

如果应用的基本功能需要多个范围，请在提示用户征求同意之前向用户说明这一点。

只有在用户明确表示有意使用需要相应范围的特定功能时，您才可以再次提示用户。在请求 OAuth 范围之前，您的应用应向用户提供相关背景信息和理由。

您应尽量减少应用一次请求的范围数量。请改为利用增量授权，在功能和功能区的上下文中请求相应范围。

使用安全的浏览器

在 Web 上，OAuth 2.0 授权请求只能通过功能齐全的 Web 浏览器发出。 在其他平台上，请务必选择正确的 OAuth 客户端类型，并根据您的平台集成 OAuth。请勿通过嵌入式浏览环境（包括移动平台上的 WebView，例如 Android 上的 WebView 或 iOS 上的 WKWebView）重定向请求。请改为使用平台专用的原生 OAuth 库或 Google 登录。

手动创建和配置 OAuth 客户端

为防止滥用，无法以编程方式创建或修改 OAuth 客户端。您必须使用 Google Developers 控制台明确确认服务条款，配置 OAuth 客户端并为 OAuth 验证做好准备。

对于自动化工作流，请考虑改用服务账号。

移除未使用的 OAuth 客户端

定期审核 OAuth 2.0 客户端，并主动删除应用不再需要或已过时的客户端。如果未使用的客户端处于已配置状态，则存在潜在的安全风险，因为如果您的客户端凭据遭到入侵，该客户端可能会被滥用。

为了进一步降低未使用客户端带来的风险，系统会 自动删除已闲置六个月的 OAuth 2.0 客户端。

建议的最佳做法是不要等待自动删除，而是主动移除未使用的客户端。这种做法可最大限度地缩小应用的受攻击面，并确保良好的安全卫生。