弃用第三方 Cookie 不会影响用户授权流程,包括这些方法

用户授权的工作原理

如果您是首次使用 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 Services JavaScript 库遵循 OAuth 2.0 标准来执行以下操作:

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

常用步骤

隐式和授权代码流程的开头相同:

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

然后,每个流程都会以不同的步骤结束。

使用隐式流程时

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

使用 Auth 代码流程时

  • 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 中所述。

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

在这两种情况下,我们强烈建议您使用 Google Identity Services 库,以缩短开发时间和工作量,并最大限度地降低安全风险,例如 OAuth 2.0 安全最佳实践