用户授权的工作原理

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

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

仅限身份验证的范围

多个范围仅用于用户身份验证:emailprofileopenid。如果您的应用仅使用这些范围,请考虑用于用户注册和登录的 JWT ID 令牌和使用 Google 帐号登录是否符合您的需求。在大多数情况下,这是最直接且最简单的用户身份验证方法。

关键术语和概念

这些指南假设您对 OAuth 2.0 概念和 IETF 标准(例如 RFC6749)有基本的了解。授权指南中会用到以下术语:

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

令牌生命周期由 Google 作为颁发者进行设置。由于各种因素,确切时长可能会有所不同。

OAuth 2.0 流程

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

建议使用授权代码流程,因为它可以提高用户安全性。 此流程还会返回一个刷新令牌,该令牌可用于在用户不在场的情况下获取访问令牌,使您的平台能够更轻松地执行异步操作,例如发送短信提醒,提醒即将在最后一分钟安排的会议即将举行。选择授权模型部分更详细地介绍了这两个流程之间的区别。

Google Identity 服务 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 进行身份验证。

虽然这不是一项强制性要求,但建议您在注册和登录 Web 应用或后端平台时使用“使用 Google 帐号登录”功能。这样可以最大程度减少所需步骤的数量,让用户感到更方便,并且您还可以选择性地轻松将访问令牌与平台上的各个帐号相关联。

例如,使用“使用 Google 帐号登录”功能会建立一个活跃的 Google 帐号会话,因此无需在发出授权请求时提示用户登录 Google 帐号。如果您选择通过用户名和密码或其他身份提供方等其他方式在您的应用中对用户进行身份验证,他们仍需要先登录 Google 帐号才能征得用户同意。

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

仅在浏览器中运行的 Web 应用可仅依赖 Google 进行用户身份验证,因此您可以选择不实现用户帐号管理系统。在这种情况下(称为隐式流程),无需将刷新令牌与用户帐号关联并管理安全存储空间。

或者,授权代码流程需要使用用户帐号系统。每位用户刷新令牌必须与后端平台上的单个帐号相关联,并存储以备后用。如何实现、使用和管理用户帐号系统是您的平台所特有的,下文不作详细讨论。

用户可以随时在 Google 帐号设置中查看或撤消同意情况。

您的 Web 应用或平台可以调用 google.accounts.oauth2.revoke 来撤消令牌并取消用户意见征求,这在用户从您的平台中删除其帐号时很有用。

其他授权选项

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

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

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