用户授权的工作原理

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

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

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

仅限身份验证的范围

有几个范围仅用于用户身份验证:emailprofileopenid。如果您的应用仅使用这些范围,请考虑 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 安全性最佳做法当前做法中所述的风险。