用户授权的工作原理

如果您是 Google Identity 服务或授权的新手或不熟悉相关概念， 请先阅读概览。

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 颁发的长期有效的用户凭据，安全地存储在您的平台上，即使用户不在场，也可用于获取新的有效访问令牌。
  • 范围 将令牌限制为定义且有限的用户数据量，如需了解详情，请参阅 适用于 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 验证自己的身份。

虽然不是必需的，但建议使用“使用 Google 账号登录”来注册和登录您的 Web 应用或后端平台。这样做可以最大限度地减少所需步骤，从而减少用户摩擦，并且可以选择将访问令牌与您平台上的各个账号相关联。

例如，使用“使用 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 安全最佳实践中所述的风险 。