此页面由 Cloud Translation API 翻译。

适用于移动应用和桌面应用的 OAuth 2.0

本文档介绍了安装在手机、平板电脑和计算机等设备上的应用如何使用 Google 的 OAuth 2.0 端点来授权访问 Google API。

OAuth 2.0 可让用户与应用共享特定数据，同时保持其用户名、密码和其他信息的私密性。例如，应用可以使用 OAuth 2.0 从用户那里获得在其 Google 云端硬盘中存储文件的权限。

已安装的应用会分发到各个设备，并且假定这些应用无法保守秘密。它们可以在用户位于应用中时或应用在后台运行时访问 Google API。

此授权流程与用于网络服务器应用的授权流程类似。主要区别在于，已安装的应用必须打开系统浏览器并提供本地重定向 URI，以处理来自 Google 授权服务器的响应。

库和示例

对于移动应用，我们建议使用最新版本的 Google Identity Services 原生库（适用于 Android）和 Google 登录原生库（适用于 iOS）。这些库可处理用户授权，并且比此处描述的较低级别协议更易于实现。

对于在不支持系统浏览器或输入功能有限的设备（例如电视、游戏机、相机或打印机）上运行的应用，请参阅适用于电视和设备的 OAuth 2.0 或在电视和输入受限的设备上登录。

前提条件

为您的项目启用 API

任何调用 Google API 的应用都需要在 API Console中启用这些 API。

如需为您的项目启用该 API，请按以下步骤操作：

Open the API Library 中的 Google API Console。
If prompted, select a project, or create a new one.
API Library 列出了所有可用的 API（按产品系列和热门程度分组）。如果列表中没有显示您要启用的 API，请使用搜索功能查找该 API，或点击该 API 所属产品系列中的查看全部。
选择您要启用的 API，然后点击启用按钮。
If prompted, enable billing.
If prompted, read and accept the API's Terms of Service.

创建授权凭据

任何使用 OAuth 2.0 访问 Google API 的应用都必须具有授权凭据，以向 Google 的 OAuth 2.0 服务器表明应用的身份。以下步骤说明了如何为项目创建凭据。然后，您的应用可以使用这些凭据来访问您为相应项目启用的 API。

Go to the Credentials page.
点击创建客户端。
以下部分介绍了 Google 授权服务器支持的客户端类型。选择适合您应用的客户端类型，为 OAuth 客户端命名，并根据需要设置表单中的其他字段。

Android

选择 Android 应用类型。
输入 OAuth 客户端的名称。此名称会显示在项目的中，用于标识客户端。
输入 Android 应用的软件包名称。此值在应用清单文件的 <manifest> 元素的 package 属性中定义。
输入应用分发的 SHA-1 签名证书指纹。
- 如果您的应用使用 Google Play 应用签名，请从 Play 管理中心的“应用签名”页面复制 SHA-1 指纹。
- 如果您自行管理密钥库和签名密钥，请使用 Java 随附的 keytool 实用程序以人类可读的格式打印证书信息。复制 keytool 输出的 Certificate fingerprints 部分中的 SHA1 值。如需了解详情，请参阅 Android 版 Google API 文档中的对客户端进行身份验证。
（可选）验证 Android 应用的所有权。
点击创建。

iOS

选择 iOS 应用类型。
输入 OAuth 客户端的名称。此名称会显示在项目的中，用于标识客户端。
输入应用的软件包标识符。软件包 ID 是应用的信息属性列表资源文件 (info.plist) 中 CFBundleIdentifier 键的值。该值最常显示在 Xcode 项目编辑器的“常规”窗格或“签名和功能”窗格中。在 Apple 的 App Store Connect 网站上，应用的“应用信息”页面的“常规信息”部分也会显示软件包 ID。
确认您为应用使用了正确的软件包 ID，因为如果您使用 App Check 功能，将无法更改该 ID。
（可选）
如果应用已在 Apple 的 App Store 中发布，请输入应用的 App Store ID。商店 ID 是每个 Apple App Store 网址中包含的数字字符串。
1. 在 iOS 或 iPadOS 设备上打开 Apple App Store 应用。
2. 搜索您的应用。
3. 选择“分享”按钮（方块和向上箭头的符号）。
4. 选择复制链接。
5. 将链接粘贴到文本编辑器中。App Store ID 是网址的最后一部分。
  示例：https://apps.apple.com/app/google/id284815942
（可选）
输入您的团队 ID。如需了解详情，请参阅 Apple 开发者账号文档中的查找您的团队 ID。
注意：如果您要为客户端启用 App Check，则必须填写团队 ID 字段。
（可选）
为您的 iOS 应用启用 App Check。启用 App Check 后，系统会使用 Apple 的 App Attest 服务来验证源自 OAuth 客户端的 OAuth 2.0 请求是否真实且来自您的应用。这有助于降低应用冒充风险。详细了解如何为 iOS 应用启用 App Check。
点击创建。

UWP

选择 Universal Windows Platform 应用类型。
输入 OAuth 客户端的名称。此名称会显示在项目的中，用于标识客户端。
输入应用的 12 字符 Microsoft Store ID。您可以在 Microsoft 合作伙伴中心的“应用管理”部分中的应用身份页面上找到此值。
点击创建。

对于 UWP 应用，重定向 URI 是使用应用的唯一软件包安全标识符 (SID) 形成的。您可以在 Visual Studio 项目的 Package.appxmanifest 文件中找到应用的 Package SID。

在 Google Cloud 控制台中创建客户端 ID 时，您必须使用以下格式指定重定向 URI，其中包含软件包 SID 的小写值：

ms-app://YOUR_APP_PACKAGE_SID

注意：OAuth 2.0 重定向需要使用 ms-app:// 方案才能正常运行。此方案用于协议激活，可让操作系统在用户于浏览器中通过身份验证后启动您的应用并传送来自 Google 的授权响应。

对于 UWP 应用，自定义 URI 方案的长度不得超过 39 个字符，如 Microsoft 文档中所述。

确定访问权限范围

有了这一范围，您不但可以让应用仅请求访问所需的资源，而且还可以让用户控制其向您的应用授予的访问权限大小。因此，所请求的范围数量与获得用户同意的可能性之间可能存在反比关系。

在开始实现 OAuth 2.0 授权之前，我们建议您确定应用需要访问权限的范围。

OAuth 2.0 API 范围文档包含您可能用于访问 Google API 的范围的完整列表。

获取 OAuth 2.0 访问令牌

以下步骤展示了您的应用如何与 Google 的 OAuth 2.0 服务器互动，以征得用户同意代表用户执行 API 请求。您的应用必须获得该同意，然后才能执行需要用户授权的 Google API 请求。

第 1 步：生成代码验证器和质询

Google 支持用于代码交换的证明密钥 (PKCE) 协议，以提高已安装应用流程的安全性。系统会为每个授权请求创建一个唯一的代码验证器，并将其转换后的值（称为“code_challenge”）发送到授权服务器以获取授权代码。

创建代码验证器

code_verifier 是一种高熵加密随机字符串，使用非保留字符 [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"，最短长度为 43 个字符，最长长度为 128 个字符。

代码验证器应具有足够的熵，以致无法猜测其值。

创建验证码请求

系统支持通过以下两种方法创建代码质询。

代码挑战生成方法
S256（推荐）	代码质询是代码验证器的 Base64网址（无填充）编码 SHA256 哈希值。 `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
plain	代码质询与上面生成的代码验证器具有相同的值。 `code_challenge` = `code_verifier`

第 2 步：向 Google 的 OAuth 2.0 服务器发送请求

如需获取用户授权，请向 Google 的授权服务器 (https://accounts.google.com/o/oauth2/v2/auth) 发送请求。此端点用于处理活跃会话查找、用户身份验证和用户意见征求。该端点只能通过 SSL 访问，并且会拒绝 HTTP（非 SSL）连接。

对于已安装的应用，授权服务器支持以下查询字符串参数：

参数

client_id

必需

应用的客户端 ID。您可以在中找到此值。

redirect_uri

必需

确定 Google 的授权服务器如何向您的应用发送响应。已安装的应用有多种重定向选项可供选择，您在设置授权凭据时会考虑使用哪种重定向方法。

该值必须与您在客户端的中配置的 OAuth 2.0 客户端的某个已获授权的重定向 URI 完全一致。如果此值与授权 URI 不匹配，您将收到 redirect_uri_mismatch 错误。

下表显示了每种方法的相应 redirect_uri 参数值：

redirect_uri 值

自定义 URI scheme

com.example.app:redirect_uri_path

或

com.googleusercontent.apps.123:redirect_uri_path

com.example.app 是您控制的网域的反向 DNS 表示法。自定义方案必须包含句点才能有效。
com.googleusercontent.apps.123 是客户端 ID 的反向 DNS 表示法。
redirect_uri_path 是可选的路径组成部分，例如 /oauth2redirect。请注意，路径应以单个斜杠开头，这与常规 HTTP 网址不同。

环回 IP 地址

http://127.0.0.1:port 或 http://[::1]:port

查询平台以获取相关的环回 IP 地址，并在随机可用的端口上启动 HTTP 监听器。将 port 替换为应用实际侦听的端口号。

请注意，移动应用对环回 IP 地址重定向选项的支持已弃用。

response_type

必需

确定 Google OAuth 2.0 端点是否返回授权代码。

将已安装应用的参数值设置为 code。

scope

必需

一个以空格分隔的范围列表，用于标识应用可以代表用户访问的资源。这些值会告知 Google 向用户显示的同意屏幕。

有了这一范围，您不但可以让应用仅请求访问所需的资源，而且还可以让用户控制其向您的应用授予的访问权限大小。因此，所请求的授权范围数量与获得用户同意的可能性之间存在反比关系。

code_challenge

建议

指定一个编码后的 code_verifier，在授权代码交换期间，该值将用作服务器端质询。如需了解详情，请参阅上文的创建代码挑战部分。

code_challenge_method

建议

指定用于对在授权代码交换期间使用的 code_verifier 进行编码的方法。此参数必须与上述 code_challenge 参数搭配使用。如果包含 code_challenge 的请求中未提供 code_challenge_method 的值，则该值默认为 plain。此参数唯一支持的值是 S256 或 plain。

state

建议

指定应用用于在授权请求与授权服务器的响应之间保持状态的任何字符串值。在用户同意或拒绝您的应用访问请求后，服务器会在 redirect_uri 的网址 fragment 标识符 (#) 中以 name=value 对的形式返回您发送的确切值。

您可以使用此参数实现多种目的，例如将用户引导至应用中的正确资源、发送随机数以及缓解跨站请求伪造。由于您的 redirect_uri 可能会被猜到，因此使用 state 值可以提高您对传入连接是身份验证请求结果的信心。如果您生成随机字符串或对 Cookie 或捕获客户端状态的其他值的哈希进行编码，则可以验证响应，以进一步确保请求和响应源自同一浏览器，从而防范跨站请求伪造等攻击。如需查看有关如何创建和确认 state 令牌的示例，请参阅 OpenID Connect 文档。

重要提示：OAuth 客户端必须按照 OAuth2 规范中的要求防止 CSRF。实现此目的的一种方法是使用 state 参数在授权请求和授权服务器的响应之间保持状态。

login_hint

可选

如果您的应用知道哪个用户正在尝试进行身份验证，则可以使用此参数向 Google 身份验证服务器提供提示。服务器会使用提示来简化登录流程，方法是预填充登录表单中的电子邮件地址字段或选择适当的多重登录会话。

将参数值设置为电子邮件地址或 sub 标识符，该标识符相当于用户的 Google ID。

注意：由于客户端无法保持 client_secret 的机密性，因此不支持对已安装的应用进行增量授权。

授权网址示例

下方的标签页显示了不同重定向 URI 选项的授权网址示例。

这两个网址完全相同，只是 redirect_uri 参数的值不同。这些网址还包含必需的 response_type 和 client_id 参数以及可选的 state 参数。为了便于阅读，每个网址都包含换行符和空格。

自定义 URI scheme

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

环回 IP 地址

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

第 3 步：Google 提示用户授予同意书

在此步骤中，用户决定是否向您的应用授予所请求的访问权限。在此阶段，Google 会显示一个同意窗口，其中显示应用的名称，以及请求权限来使用用户授权凭据进行访问的 Google API 服务，还会显示要授予的访问范围摘要。然后，用户可以同意授予对应用所请求的一个或多个范围的访问权限，也可以拒绝该请求。

在此阶段，您的应用无需执行任何操作，只需等待 Google 的 OAuth 2.0 服务器的响应，以确定是否授予了任何访问权限。以下步骤将说明该响应。

错误

对 Google 的 OAuth 2.0 授权端点的请求可能会显示面向用户的错误消息，而不是预期的身份验证和授权流程。下表列出了常见的错误代码和建议的解决方法。

`admin_policy_enforced`

由于 Google Workspace 管理员的政策，相应 Google 账号无法授权一个或多个请求的范围。如需详细了解管理员如何限制对所有范围或敏感范围和受限范围的访问权限，直到明确授予您的 OAuth 客户端 ID 访问权限为止，请参阅 Google Workspace 管理员帮助文章控制哪些第三方应用和内部应用可以访问 Google Workspace 数据。

`disallowed_useragent`

授权端点显示在 Google 的 OAuth 2.0 政策禁止使用的嵌入式用户代理中。

Android

Android 开发者在 android.webkit.WebView 中打开授权请求时，可能会遇到此错误消息。开发者应改为使用 Android 库，例如 Google Sign-In for Android 或 OpenID Foundation 的 AppAuth for Android。

当 Android 应用在嵌入式 User-Agent 中打开常规 Web 链接，并且用户从您的网站导航到 Google 的 OAuth 2.0 授权端点时，Web 开发者可能会遇到此错误。开发者应允许在操作系统（包括 Android 应用链接处理程序或默认浏览器应用）的默认链接处理程序中打开常规链接。Android 自定义标签页库也是受支持的选项。

iOS

iOS 和 macOS 开发者在 WKWebView 中打开授权请求时，可能会遇到此错误。开发者应改用 iOS 库，例如 Google Sign-In for iOS 或 OpenID Foundation 的 AppAuth for iOS。

当 iOS 或 macOS 应用在嵌入式用户代理中打开常规网页链接，并且用户从您的网站导航到 Google 的 OAuth 2.0 授权端点时，Web 开发者可能会遇到此错误。开发者应允许在操作系统默认的链接处理程序中打开常规链接，包括 Universal Links 处理程序或默认浏览器应用。SFSafariViewController 库也是受支持的选项。

`org_internal`

相应请求中的 OAuth 客户端 ID 属于一个项目，该项目限制对特定 Google Cloud 组织中的 Google 账号的访问权限。如需详细了解此配置选项，请参阅“设置 OAuth 权限请求页面”帮助文章中的用户类型部分。

`deleted_client`

用于发出请求的 OAuth 客户端已被删除。删除操作可以手动执行，也可以在出现未使用的客户端时自动执行。已删除的客户可以在删除后的 30 天内恢复。了解详情。

`invalid_grant`

如果您使用的是代码验证器和质询，则 code_callenge 参数无效或缺失。确保 code_challenge 参数设置正确。

刷新访问令牌时，令牌可能已过期或失效。再次验证用户身份，并征得用户同意以获取新令牌。如果您仍然看到此错误，请确保您的应用已正确配置，并且您在请求中使用了正确的令牌和参数。否则，用户账号可能已被删除或停用。

`redirect_uri_mismatch`

授权请求中传递的 redirect_uri 与 OAuth 客户端 ID 的已获授权的重定向 URI 不匹配。在中查看已获授权的重定向 URI 。

传递的 redirect_uri 可能对相应客户类型无效。

redirect_uri 参数可能指的是已弃用且不再受支持的 OAuth 带外 (OOB) 流程。请参阅迁移指南，更新您的集成。

`invalid_request`

您发出的请求存在问题。这可能是由多种原因导致的：

请求格式不正确
请求缺少必需参数
相应请求使用的授权方法不受 Google 支持。验证您的 OAuth 集成是否使用了推荐的集成方法
重定向 URI 使用的是自定义 scheme：如果您看到错误消息Chrome 应用不支持自定义 URI scheme或未为 Android 客户端启用自定义 URI scheme，则表示您使用的是 Chrome 应用不支持的自定义 URI scheme，并且该 scheme 在 Android 上默认处于停用状态。详细了解自定义 URI scheme 替代方案

第 4 步：处理 OAuth 2.0 服务器响应

应用接收授权响应的方式取决于其使用的重定向 URI scheme。无论采用哪种方案，响应都会包含授权代码 (code) 或错误 (error)。例如，error=access_denied 表示用户拒绝了请求。

如果用户向您的应用授予访问权限，您可以按照下一步中的说明，将授权代码换成访问令牌和刷新令牌。

第 5 步：将授权代码换成刷新令牌和访问令牌

如需使用授权代码交换访问令牌，请调用 https://oauth2.googleapis.com/token 端点并设置以下参数：

字段
`client_id`	从获取的客户端 ID。
`client_secret`	从获取的客户端密钥。
`code`	从初始请求返回的授权代码。
`code_verifier`	您在第 1 步中创建的代码验证器。
`grant_type`	根据 OAuth 2.0 规范中的定义，此字段的值必须设置为 `authorization_code`。
`redirect_uri`	中为您的项目列出的重定向 URI 之一（针对给定的`client_id`）。

以下代码段显示了一个示例请求：

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

Google 会返回一个包含短期有效的访问令牌和刷新令牌的 JSON 对象，以响应此请求。

响应包含以下字段：

字段
`access_token`	您的应用发送的用于授权 Google API 请求的令牌。
`expires_in`	访问令牌的剩余生命周期（以秒为单位）。
`id_token`	注意：仅当您的请求包含身份范围（例如 `openid`、`profile` 或 `email`）时，系统才会返回此属性。该值是一个 JSON Web 令牌 (JWT)，其中包含有关用户的数字签名身份信息。
`refresh_token`	可用于获取新访问令牌的令牌。刷新令牌在用户撤消访问权限或刷新令牌过期之前一直有效。请注意，系统始终会为已安装的应用返回刷新令牌。
`refresh_token_expires_in`	刷新令牌的剩余有效期（以秒为单位）。仅当用户授予基于时间的访问权限时，才会设置此值。
`scope`	由 `access_token` 授予的访问权限范围，表示为以空格分隔且区分大小写的字符串列表。
`token_type`	返回的令牌的类型。目前，此字段的值始终设置为 `Bearer`。

以下代码段显示了示例响应：

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

第 6 步：检查用户授予了哪些范围

当您请求多项权限（范围）时，用户可能不会向您的应用授予对所有这些权限的访问权限。您的应用必须验证实际授予了哪些范围，并妥善处理某些权限被拒绝的情况，通常是通过停用依赖于这些被拒绝范围的功能。

不过，也有例外情况。具有全网域授权的 Google Workspace 企业应用，或标记为可信的应用，会绕过精细权限同意页面。对于这些应用，用户不会看到精细的权限同意屏幕。相反，您的应用要么会获得所有请求的范围，要么不会获得任何范围。

如需了解更详细的信息，请参阅如何处理精细权限。

如需检查用户是否已向您的应用授予对特定范围的访问权限，请检查访问令牌响应中的 scope 字段。access_token 授予的访问权限范围，以空格分隔的区分大小写的字符串列表表示。

例如，以下示例访问令牌响应表明用户已向您的应用授予只读的云端硬盘活动和日历活动权限：

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

调用 Google API

应用获得访问令牌后，如果 API 所需的访问范围已获授权，您就可以使用该令牌代表指定的用户账号调用 Google API。为此，请在向 API 发出的请求中添加访问令牌，方法是添加 access_token 查询参数或 Authorization HTTP 标头 Bearer 值。如果可以，最好使用 HTTP 标头，因为查询字符串往往会显示在服务器日志中。在大多数情况下，您可以使用客户端库来设置对 Google API 的调用（例如，调用 Drive Files API 时）。

您可以在 OAuth 2.0 Playground 中试用所有 Google API 并查看其权限范围。

HTTP GET 示例

使用 Authorization: Bearer HTTP 标头对 drive.files 端点（即 Drive Files API）的调用可能如下所示。请注意，您需要指定自己的访问令牌：

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

以下是使用 access_token 查询字符串参数针对已通过身份验证的用户对同一 API 的调用：

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

`curl` 示例

您可以使用 curl 命令行应用测试这些命令。下面是一个使用 HTTP 标头选项（首选）的示例：

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

或者，也可以使用查询字符串参数选项：

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

刷新访问令牌

访问令牌会定期过期，并成为相关 API 请求的无效凭据。如果您请求离线访问与令牌关联的范围，则可以刷新访问令牌，而不提示用户授予权限（包括用户不在场时）。

如需刷新访问令牌，您的应用会向 Google 的授权服务器 (https://oauth2.googleapis.com/token) 发送 HTTPS POST 请求，其中包含以下参数：

字段
`client_id`	从 API Console获取的客户端 ID。
`client_secret`	从 API Console获取的客户端密钥。（`client_secret` 不适用于注册为 Android、iOS 或 Chrome 应用的客户端发出的请求。）
`grant_type`	如 OAuth 2.0 规范中所定义，此字段的值必须设置为 `refresh_token`。
`refresh_token`	从授权代码交换中返回的刷新令牌。

以下代码段显示了一个示例请求：

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

只要用户未撤消授予应用的访问权限，令牌服务器就会返回包含新访问令牌的 JSON 对象。以下代码段显示了示例响应：

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

请注意，系统会限制刷新令牌的颁发数量；每个客户端/用户组合有一个限制，所有客户端的每个用户也有一个限制。您应将刷新令牌保存在长期存储空间中，并在刷新令牌保持有效期间继续使用。如果您的应用请求的刷新令牌过多，可能会达到这些限制，在这种情况下，较旧的刷新令牌将停止工作。

令牌撤消

在某些情况下，用户可能希望撤消授予应用的访问权限。用户可以前往账号设置撤消访问权限。如需了解详情，请参阅支持文档有权访问您账号的第三方网站和应用中的“撤消网站或应用访问权限”部分。

应用还可以通过程序化方式撤消授予自身的访问权限。在以下情况下，以程序化方式撤消授权非常重要：用户退订、移除应用，或者应用所需的 API 资源发生了重大变化。换句话说，移除过程的一部分可能包括 API 请求，以确保移除之前授予应用的权限。

如需以编程方式撤消令牌，您的应用可以向 https://oauth2.googleapis.com/revoke 发出请求，并将令牌作为参数包含在请求中：

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

令牌可以是访问令牌，也可以是刷新令牌。如果令牌是访问令牌，并且具有对应的刷新令牌，则刷新令牌也会被撤消。

如果撤消成功处理，则响应的 HTTP 状态代码为 200。对于错误情况，系统会返回 HTTP 状态代码 400 以及错误代码。

应用重定向方法

自定义 URI scheme（Android、iOS、UWP）

自定义 URI 架构是一种深层链接，使用自定义架构打开您的应用。

在 Android 上使用自定义 URI scheme 的替代方案

使用推荐的替代方案，该方案可将 OAuth 2.0 响应直接传递给您的应用，从而无需重定向 URI。

如何迁移到 Google Identity 服务 Android 库

如果您在 Android 上为 OAuth 集成使用自定义方案，则需要完成以下操作，才能完全迁移到使用推荐的 Google Identity Services Android 库：

更新代码以使用 Google Identity Services Android 库。
在 Google Cloud 控制台中停用对自定义方案的支持。

以下步骤详细介绍了如何迁移到 Google Identity Services Android 库：

更新您的代码以使用 Google Identity Services Android 库：
1. 检查您的代码，找出您向 Google 的 OAuth 2.0 服务器发送请求的位置；如果使用自定义方案，您的请求将如下所示：
```
  https://accounts.google.com/o/oauth2/v2/auth?
  scope=<SCOPES>&
  response_type=code&
  &state=<STATE>&
  redirect_uri=com.example.app:/oauth2redirect&
  client_id=<CLIENT_ID>
  
```
  com.example.app:/oauth2redirect 是上述示例中的自定义 scheme 重定向 URI。如需详细了解自定义 URI scheme 值的格式，请参阅 redirect_uri 参数定义。
2. 记下 scope 和 client_id 请求参数，您需要使用这些参数来配置 Google 登录 SDK。
  注意：如果您使用的是第三方库，请查看该库的配置文件以查找这些信息。
3. 按照授权访问 Google 用户数据说明设置 SDK。您可以跳过设置 Google Cloud 控制台项目 这一步，因为您会重复使用在上一步中检索到的 client_id。
4. 按照请求用户操作所需的权限说明操作。这包括以下步骤：
  1. 向用户请求权限。
  2. 使用 getServerAuthCode 方法检索您要请求权限的范围的授权代码。
  3. 将授权代码发送到应用的后端，以换取访问令牌和刷新令牌。
  4. 使用检索到的访问令牌代表用户调用 Google API。
  注意：如果您的应用仅需要身份验证范围，请改为按照这些说明使用推荐的凭据管理器库。
在 Google API 控制台中停用对自定义方案的支持：
1. 前往 OAuth 2.0 凭据列表，然后选择您的 Android 客户端。
2. 前往高级设置部分，取消选中启用自定义 URI scheme 复选框，然后点击保存以停用自定义 URI scheme 支持。

启用自定义 URI scheme

如果推荐的替代方案不适合您，您可以按照以下说明为 Android 客户端启用自定义 URI 方案：

前往 OAuth 2.0 凭据列表，然后选择您的 Android 客户端。
前往高级设置部分，勾选启用自定义 URI 方案复选框，然后点击保存以启用自定义 URI 方案支持。

在 Chrome 应用中使用自定义 URI scheme 的替代方案

使用 Chrome Identity API，该 API 可将 OAuth 2.0 响应直接传递给您的应用，从而无需重定向 URI。

环回 IP 地址（macOS、Linux、Windows 桌面设备）

如需使用此网址接收授权代码，您的应用必须在本地网络服务器上进行监听。许多平台（但并非所有平台）都支持此功能。不过，如果您的平台支持此方法，建议您使用此机制来获取授权代码。

当应用收到授权响应时，为了获得最佳可用性，应用应通过显示一个 HTML 页面来做出响应，该页面会指示用户关闭浏览器并返回到您的应用。

建议用法	macOS、Linux 和 Windows 桌面应用（但不包括通用 Windows 平台应用）
表单值	将应用类型设置为桌面应用。

注意：如需详细了解环回 IP 地址，请参阅 redirect_uri 参数定义。也可以使用 localhost 代替环回 IP，但此配置可能会导致客户端防火墙出现问题。大多数（但并非所有）防火墙都允许环回通信。

手动复制/粘贴（已弃用）

保护您的应用

验证应用所有权（Android、Chrome）

您可以验证应用的所有权，以降低应用冒充风险。

Android

如需完成验证流程，您可以使用自己的 Google Play 开发者账号（如果有）以及在 Google Play 管理中心注册的应用。必须满足以下要求，才能成功完成验证：

您必须在 Google Play 管理中心内注册一个应用，该应用具有与您要完成验证的 Android OAuth 客户端相同的软件包名称和 SHA-1 签名证书指纹。
您必须在 Google Play 管理中心内拥有相应应用的管理员权限。详细了解 Google Play 管理中心内的访问权限管理。

在 Android 客户端的验证应用所有权部分中，点击验证所有权按钮以完成验证流程。

如果验证成功，系统会显示一条通知，确认验证流程已成功完成。否则，系统会显示错误提示。

如需修正验证失败问题，请尝试以下操作：

确保您要验证的应用是 Google Play 管理中心内的已注册应用。
确保您在 Google Play 管理中心内拥有该应用的管理员权限。

Chrome

若要完成验证流程，您需要使用 Chrome 应用商店开发者账号。如需成功完成验证，必须满足以下要求：

您必须在 Chrome 应用商店开发者信息中心中注册一个商品，且该商品的 ID 与您要完成验证的 Chrome 扩展程序 OAuth 客户端的 ID 相同。
您必须是 Chrome 应用商店商品的发布者。详细了解 Chrome 应用商店开发者信息中心内的访问权限管理。

在 Chrome 扩展程序客户端的验证应用所有权部分中，点击验证所有权按钮以完成验证流程。

注意：授予账号访问权限后，请等待几分钟再完成验证流程。

如果验证成功，系统会显示一条通知，确认验证流程已成功完成。否则，系统会显示错误提示。

如需修正验证失败问题，请尝试以下操作：

确保 Chrome 应用商店开发者信息中心内已注册的商品的商品 ID 与您要完成验证的 Chrome 扩展程序 OAuth 客户端的商品 ID 相同。
确保您是应用的发布者，也就是说，您必须是应用的个人发布者或应用群组发布者的成员。详细了解 Chrome 应用商店开发者信息中心内的访问权限管理。
如果您刚刚更新了群组发布方列表，请验证 Chrome 应用商店开发者信息中心内的群组发布方成员资格列表是否已同步。详细了解如何同步发布商会员名单。

App Check（仅限 iOS）

App Check 功能使用 Apple 的 App Attest 服务来验证向 Google OAuth 2.0 端点发出的请求是否来自真实的应用，从而帮助保护您的 iOS 应用免遭未经授权的使用。这有助于降低应用冒充风险。

为 iOS 客户端启用 App Check

必须满足以下要求，才能成功为 iOS 客户端启用 App Check：

您必须为 iOS 客户端指定团队 ID。
您不得在软件包 ID 中使用通配符，因为通配符可能会解析为多个应用。这意味着软件包 ID 不得包含星号 (*) 符号。

如需启用 App Check，请在 iOS 客户端的修改视图中，将使用 Firebase App Check 保护您的 OAuth 客户端免遭滥用切换按钮切换为开启状态。

启用 App Check 后，您将在 OAuth 客户端的修改视图中看到与客户端发出的 OAuth 请求相关的指标。在您强制执行 App Check 之前，系统不会屏蔽来自未经验证的来源的请求。“指标监控”页面中的信息可帮助您确定何时开始强制执行。

为 iOS 应用启用 App Check 时，您可能会看到与 App Check 功能相关的错误。如需修正这些错误，请尝试以下操作：

验证您指定的软件包 ID 和团队 ID 是否有效。
确认您未对软件包 ID 使用通配符。

为 iOS 客户端强制执行 App Check

为应用启用 App Check 后，系统不会自动阻止无法识别的请求。如需强制执行此保护措施，请前往 iOS 客户端的编辑视图。在该页面上，您会在 Google Identity for iOS 部分下看到页面右侧的 App Check 指标。这些指标包含以下信息：

已验证的请求数 - 具有有效 App Check 令牌的请求。启用 App Check 强制执行后，只有此类别的请求会成功。
未验证的请求数：可能过时的客户端请求 - 缺少 App Check 令牌的请求；这些请求可能来自不包含 App Check 实现的旧版应用。
未验证的请求数：未知来源的请求 - 缺少 App Check 令牌且看起来不像来自您的应用的请求。
未经验证的请求数：无效请求 - 具有无效 App Check 令牌的请求，可能来自企图冒充您的应用的不可信客户端，或者来自模拟的环境。

请查看这些指标，了解强制执行 App Check 会对用户产生哪些影响。

如需强制执行 App Check，请点击强制执行按钮并确认您的选择。强制执行生效后，来自客户端的所有未经验证的请求都将被拒绝。

注意：启用强制执行后，更改最长可能需要 15 分钟才能生效。

取消强制执行 iOS 客户端的 App Check

为应用取消强制执行 App Check 后，系统将停止强制执行，并允许客户端向 Google OAuth 2.0 端点发送所有请求，包括未经验证的请求。

如需针对 iOS 客户端取消强制执行 App Check，请前往 iOS 客户端的修改视图，然后点击取消强制执行按钮并确认您的选择。

注意：取消强制执行 App Check 后，更改最长可能需要 15 分钟才能生效。

为 iOS 客户端停用 App Check

为应用停用 App Check 后，系统将停止所有 App Check 监控和强制执行。考虑改为不强制执行 App Check，以便继续监控客户端的指标。

如需为 iOS 客户端停用 App Check，请前往 iOS 客户端的修改视图，然后关闭使用 Firebase App Check 保护您的 OAuth 客户端免遭滥用切换按钮。

注意：停用 App Check 后，更改最长可能需要 15 分钟才能生效。

基于时间的访问权限

基于时间的访问权限允许用户在有限的时间内授予您的应用对其数据的访问权限，以完成某项操作。在意见征求流程中，部分 Google 产品会提供基于时间的访问权限，让用户可以选择在有限的时间内授予访问权限。例如， Data Portability API 可实现一次性数据转移。

当用户向您的应用授予基于时间的访问权限时，刷新令牌将在指定时长后过期。请注意，在特定情况下，刷新令牌可能会提前失效；如需了解详情，请参阅这些情况。在授权码交换响应中返回的 refresh_token_expires_in 字段表示在这种情况下刷新令牌的剩余有效时间。

延伸阅读

IETF 当前最佳实践 OAuth 2.0 for Native Apps 确立了本文档中记录的许多最佳实践。

实现跨账号保护

为保护用户账号，您还应采取一项措施，即利用 Google 的跨账号保护服务来实现跨账号保护。此服务可让您订阅安全事件通知，这些通知会向您的应用提供有关用户账号重大变更的信息。然后，您可以根据自己决定如何响应事件来采取行动。

Google 的跨账号保护服务发送给您应用的事件类型的一些示例包括：

https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
https://schemas.openid.net/secevent/oauth/event-type/token-revoked
https://schemas.openid.net/secevent/risc/event-type/account-disabled

如需详细了解如何实现跨账号保护，以及查看可用事件的完整列表，请参阅使用跨账号保护功能保护用户账号页面。

适用于移动应用和桌面应用的 OAuth 2.0 使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

库和示例

前提条件

为您的项目启用 API

创建授权凭据

Android

iOS

UWP

确定访问权限范围

获取 OAuth 2.0 访问令牌

第 1 步：生成代码验证器和质询

创建代码验证器

创建验证码请求

第 2 步：向 Google 的 OAuth 2.0 服务器发送请求

授权网址示例

自定义 URI scheme

环回 IP 地址

第 3 步：Google 提示用户授予同意书

错误

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

第 4 步：处理 OAuth 2.0 服务器响应

第 5 步：将授权代码换成刷新令牌和访问令牌

第 6 步：检查用户授予了哪些范围

调用 Google API

HTTP GET 示例

curl 示例

刷新访问令牌

令牌撤消

应用重定向方法

自定义 URI scheme（Android、iOS、UWP）

在 Android 上使用自定义 URI scheme 的替代方案

如何迁移到 Google Identity 服务 Android 库

启用自定义 URI scheme

在 Chrome 应用中使用自定义 URI scheme 的替代方案

环回 IP 地址（macOS、Linux、Windows 桌面设备）

手动复制/粘贴（已弃用）

保护您的应用

验证应用所有权（Android、Chrome）

Android

Chrome

App Check（仅限 iOS）

为 iOS 客户端启用 App Check

为 iOS 客户端强制执行 App Check

取消强制执行 iOS 客户端的 App Check

为 iOS 客户端停用 App Check

基于时间的访问权限

延伸阅读

实现跨账号保护

适用于移动应用和桌面应用的 OAuth 2.0

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` 示例