最佳实践

安全地处理客户端凭证

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

安全地处理用户令牌

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

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

此外，还请考虑以下适用于您平台的最佳实践：

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

使用 DPoP 限制令牌发送方

为了保护您的应用免遭令牌盗用和重放攻击，请考虑使用 DPoP（Demonstrating Proof-of-Possession，所有权证明）对令牌进行发送者限制。 虽然标准不记名令牌可供任何拦截它们的方使用，但 DPoP 令牌会通过加密方式绑定到由客户端生成并持有的唯一密钥对。

使用 DPoP 时，客户端在请求或刷新令牌时会向令牌端点提供证明（已签名的 JSON Web 令牌）。此证明表明客户端拥有与绑定到令牌的公钥相对应的私钥。如果与 DPoP 绑定的刷新令牌泄露，攻击者在没有私钥的情况下无法重放该令牌。

DPoP 与 PKCE 搭配使用，可提供全面的保护：

• PKCE 可在初始重定向流程中保护授权代码。
• DPoP 可保护长期有效的刷新令牌，防止其在遭到入侵时受到重放攻击。

如果您的应用符合以下条件，强烈建议您采用 DPoP：

• 作为已安装的应用或桌面应用（或与后端到前端服务器配对的单页应用）运行，其中刷新令牌可能更容易被渗漏。
• 访问高度敏感的数据或高价值 API，令牌泄露的影响很大。
• 需要满足强制要求使用发送者限制令牌的严格合规性或安全标准。

如需详细了解如何构建 DPoP 证明和请求 DPoP 绑定令牌，请参阅 DPoP 采用指南。

使用 state 参数

在处理 OAuth 2.0 响应之前，请确认从 Google 收到的 state 与您在授权请求中发送的 state 一致。state 参数应是由您的应用生成的唯一且不可猜测的值。

使用 state 参数有助于确保是用户（而非恶意脚本）在发出请求，并降低跨站请求伪造 (CSRF) 攻击的风险。

处理刷新令牌撤消和过期

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

使用增量授权

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

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

请始终结合具体使用情境请求范围，以便用户了解您的应用为何请求访问权限以及将如何使用数据。

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

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

处理多个范围的同意情况

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

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

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

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

使用安全的浏览器

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

手动创建和配置 OAuth 客户端

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

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

移除未使用的 OAuth 客户端

定期审核您的 OAuth 2.0 客户端，并主动删除应用不再需要或已过时的客户端。如果您的客户端凭据遭到泄露，则配置的未使用客户端可能会被滥用，从而带来潜在的安全风险。

为了进一步降低未使用客户端带来的风险，不活跃 6 个月的 OAuth 2.0 客户端会被 自动删除。

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