最佳实践

本页介绍了与 OAuth 2.0 集成的一般最佳实践。除了针对您所用应用类型和开发平台的任何具体指南之外，还应考虑这些最佳实践。另请参阅有关准备好正式版应用的建议和 Google 的 OAuth 2.0 政策。

安全地处理客户端凭据

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

安全地处理用户令牌

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

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

此外，请考虑针对您的平台采用以下最佳实践：

处理刷新令牌撤消和过期

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

使用增量授权

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

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

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

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

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

处理多种范围的用户意见征求

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

如果应用的基本功能需要多个范围，请先向用户说明这一点，然后再提示用户同意。

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

您应尽量减少应用一次请求的镜重数量。而是应利用增量授权，在功能和特性的上下文中请求镜重。

使用安全的浏览器

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

手动创建和配置 OAuth 客户端

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

对于自动化工作流，不妨改用服务账号。

移除未使用的 OAuth 客户端

定期审核您的 OAuth 2.0 客户端，并主动删除应用不再需要或已过时的所有客户端。保留未使用的客户端配置会带来潜在的安全风险，因为如果您的客户端凭据遭到破坏，客户端可能会被滥用。

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

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