最佳实践

安全地处理客户端凭据

OAuth 客户端凭据用于标识您的应用的身份，因此应谨慎处理。仅将这些凭据存储在安全的存储空间中，例如使用 Google Cloud Secret Manager 等 Secret Manager。不要对凭据进行硬编码，也不要将凭据提交到代码库或公开发布凭据。

安全地处理用户令牌

用户令牌包括应用使用的刷新令牌和访问令牌。以静态方式安全存储令牌，且绝不以明文形式传输这些令牌。使用适合您平台的安全存储系统，例如 Android 上的密钥库、iOS 和 macOS 上的 Keychain Services 或 Windows 上的 Credential Locker。

尽快撤消不再需要的令牌，并将其从您的系统中永久删除。

此外，还应考虑适用于您的平台的以下最佳做法：

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

处理刷新令牌的撤消和到期

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

使用增量授权

如果您的应用需要相应功能，可使用增量授权来请求适当的 OAuth 范围。

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

始终在上下文中请求范围，以帮助您的用户了解应用请求访问权限的原因以及数据的使用方式。

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

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

处理多个范围的同意情况

同时请求多个范围时，用户可能不会授予您已请求的所有 OAuth 范围。您的应用应通过停用相关功能来处理作用域拒绝事件。

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

只有在用户明确表示使用需要作用域的特定功能的意图后，您才能再次提示用户。在请求 OAuth 范围之前，您的应用应为用户提供相关上下文和理由。

您应尽量减少应用一次性请求的范围数。相反，请利用增量授权来请求特性和功能范围。

使用安全的浏览器

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

手动创建和配置 OAuth 客户端

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

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