用户授权的工作原理

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

如果您不熟悉或不熟悉 Google Identity Services 或授权，请先阅读概览。

Google 提供了包含授权功能的 JavaScript 库，可帮助您管理范围、征得用户同意，并更轻松地使用标准 OAuth 2.0 流程。在用户的浏览器中运行的 Web 应用使用此库来管理 OAuth 2.0 隐式流程，或启动在后端平台上完成的授权代码流程。

仅限身份验证的范围

有几个范围仅用于用户身份验证：email、profile 和 openid。如果您的应用仅使用这些范围，请考虑 JWT ID 令牌和使用 Google 帐号登录供用户注册和登录的方式是否符合您的需求。在大多数情况下，这是最简单直接的方法，可用于用户身份验证。

关键术语和概念

这些指南假定您对 OAuth 2.0 概念和 IETF 标准（例如 RFC6749）有基本的了解。授权指南中使用了以下术语：

  • 访问令牌是 Google 颁发的每个用户凭据的短期有效凭据，用于安全调用 Google API 和访问用户数据。
  • 授权代码是 Google 签发的临时代码，用于安全地识别通过浏览器登录 Google 帐号的各个用户。您的后端平台使用此代码交换访问令牌和刷新令牌。
  • 刷新令牌是 Google 长期签发的每个用户凭据，安全地存储在您的平台上，可用于获取新的有效访问令牌（即使用户不存在也是如此）。
  • Scope 将令牌限制为已定义且数量有限的用户数据。如需了解详情，请参阅 Google API 的 OAuth 2.0 范围。
  • 弹出模式是根据用户浏览器中运行的 JavaScript 回调进行的授权代码流程。Google 会调用您的回调处理程序，该处理程序随后负责将身份验证代码发送到您的平台，具体方式由您决定。
  • 重定向模式是基于 HTTP 重定向的授权代码流。用户代理会首先重定向到 Google，而第二个是从 Google 重定向到您的平台的授权代码端点，其中包含该代码。

令牌的生命周期由 Google（作为发卡机构）设置。实际时长可能会因各种因素而异。

OAuth 2.0 流程

其中介绍了隐式和授权代码这两个流程。两者都会返回适合与 Google API 配合使用的访问令牌。

我们推荐使用授权代码流，因为它可以提升用户的安全性。此外，此流程还会返回一个刷新令牌，利用该令牌，可以在用户不存在时获取访问令牌，从而让您的平台可以更轻松地执行异步操作，例如向即将在最后一分钟安排的即将召开的会议发送短信提醒。选择授权模式部分更详细地介绍了这两个流程之间的差异。

Google 身份服务 JavaScript 库遵循 OAuth 2.0 标准，可以执行以下操作：

  • 管理隐式流程，使您的浏览器内 Web 应用能够快速轻松地从 Google 获取调用 Google API 所需的访问令牌。
  • 从用户的浏览器启动授权代码流程。

常用步骤

隐式和授权代码流程以相同的方式开始：

  1. 您的应用请求访问一个或多个范围。
  2. Google 会向用户显示意见征求对话框，并在必要时先让用户登录其 Google 帐号。
  3. 用户逐个批准请求的范围。

然后，每个流程会完成不同的步骤。

使用隐式流程时

  • Google 使用回调处理程序来通知您的应用用户意见征求结果，并针对任何已获批准的范围返回访问令牌。

使用授权代码流程时

  • Google 会以每位用户的授权代码作为响应：
    • 在重定向模式下，代码会返回到您的平台的授权代码端点。
    • 在弹出式窗口模式下，代码会返回到浏览器应用的回调处理程序，用户无需离开您的网站。
  • 从第 4 步：处理 OAuth 2.0 服务器响应开始，您的后端平台会完成与 Google 的服务器到服务器交换，最终会将每个用户刷新令牌和访问令牌返回到您的平台。

在获取访问令牌之前，各个用户必须同意您的应用访问所请求的范围。为此，Google 会在上述第 2 步中显示一个意见征求对话框，并将结果记录在 myaccount.google.com/permissions 中。

系统会向用户显示应用名称、徽标、隐私权政策、服务条款和所请求的范围，以及批准或取消请求的选项。

在图 1 中，显示了单个范围的意见征求对话框。请求单个范围时，无需批准或拒绝范围。

包含“取消”或“继续”按钮以及一个作用域且不显示复选框的用户意见征求对话框。

图 1：具有单一范围的用户同意对话框。

在图 2 中，显示了多个范围的意见征求对话框。如果请求多个范围，则需要单独的复选框来允许用户批准或拒绝每个范围。

包含“取消”或“继续”按钮以及多个范围的用户同意对话框，每个范围都有一个复选框选择器。

图 2：包含多个范围的用户意见征求对话框。

用户帐号

必须要有 Google 帐号才能记录用户意见征求情况和颁发访问令牌。 在此之前，个人用户必须已通过登录 Google 帐号向 Google 进行身份验证。

虽然不是强制性要求，但还是建议您使用“使用 Google 帐号登录”功能并登录 Web 应用或后端平台。这样可以最大限度地减少所需步骤的数量，并让您能够轻松地将访问令牌与平台上的个别帐号相关联，从而减少用户体验。

例如，使用“使用 Google 帐号登录”功能会创建一个有效的 Google 帐号会话，从而避免以后发出授权请求时提示用户登录 Google 帐号。如果您选择通过其他方式（例如用户名和密码）或其他身份提供方对应用进行身份验证，他们仍需要先登录 Google 帐号以征得用户同意。

在授权初始化期间（通常是用户的 Google 帐号的电子邮件地址）添加提示后，Google 会跳过帐号选择器的显示步骤，为用户省去了一步。“使用 Google 帐号登录”功能返回的 ID 令牌凭据包含用户的电子邮件地址。

仅在浏览器中运行的 Web 应用可以仅依赖于 Google 进行用户身份验证，选择不实现用户帐号管理系统。 在这样的场景（称为隐式流程）中，无需将刷新令牌与用户帐号和管理安全存储空间相关联。

或者，授权代码流需要使用用户帐号系统。每位用户的刷新令牌必须与后端平台上的单个帐号相关联，并存储起来供日后使用。如何实现、使用和管理用户帐号系统为您的平台独有，我们不会对此进行详细介绍。

用户可以随时通过其 Google 帐号设置查看或撤消同意。

（可选）您的 Web 应用或平台可以调用 google.accounts.oauth2.revoke 以撤消令牌并移除用户同意声明，这在用户从您的平台中删除其帐号时非常有用。

其他授权选项

或者，如客户端 Web 应用的 OAuth 2.0 中所述，浏览器可以通过直接调用 Google 的 OAuth 2.0 端点，使用隐式流程获取访问令牌。

同样，对于授权代码流程，您可以选择实现自己的方法，并按照为网络服务器应用使用 OAuth 2.0 中的步骤操作。

在这两种情况下，我们强烈建议您使用 Google 身份服务库来缩短开发时间和工作量，并最大限度地降低安全风险，例如 OAuth 2.0 安全性最佳做法当前做法中所述的风险。