概述

帐户关联使Google帐户所有者可以快速,无缝且安全地连接到您的服务。您可以选择实施Google帐户关联,以将平台中的用户数据与Google应用和服务共享。

安全的OAuth 2.0协议可让您安全地将用户的Google帐户与其平台上的帐户相关联,从而授予Google应用程序和设备对您的服务的访问权限。

用户可以链接或取消链接他们的帐户,还可以选择使用Google帐户链接在您的平台上创建一个新帐户。

用例

实施Google帐户关联的一些原因包括:

  • 使用Google应用和服务共享您平台中的用户数据。

  • 使用Google TV播放视频和电影内容。

  • 使用Google Home应用和Google助手管理和控制与Google Smart Home连接的设备,“嘿Google开灯”。

  • 通过“对话操作”(“嗨,谷歌,从星巴克订购我的平常物品”)来创建用户自定义的Google助手体验和功能。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

  • 将用户的Google帐户关联到奖励合作伙伴帐户后,可以通过在YouTube上查看合格的实时流来使用户获得奖励。

  • 在注册过程中,使用Google帐户个人资料中达成共识的共享数据预先填充新帐户。

支持的功能

Google帐户链接支持以下功能:

  • 使用OAuth链接隐式流程快速轻松地共享您的数据。

  • 通过OAuth链接授权代码流提供改进的安全性。

  • 登录现有用户或注册新的Google验证用户到您的平台,征得他们的同意,并通过精简链接安全地共享数据。

  • 使用App Flip减少摩擦。在受信任的Google应用中,一键安全地打开您经过验证的Android或iOS应用,然后一键授予用户同意并链接帐户。

  • 通过定义仅共享必需数据的自定义范围来提高用户隐私,通过明确定义数据的使用方式来提高用户信任度。

  • 取消关联帐户可以撤消对平台上托管的数据和服务的访问。实施可选的令牌吊销终结点,可以使您与Google发起的事件保持同步,而跨帐户保护(RISC)则可以让您将平台上发生的所有未关联事件通知Google。

帐户关联流程

Google帐户链接共有3个流程,所有这些流程均基于OAuth,并且需要您管理或控制OAuth 2.0兼容的授权和令牌交换端点。

在链接过程中,您在获得帐户持有人同意链接其帐户和共享数据后,会向单个Google帐户向Google发出访问令牌。

OAuth链接(“ Web OAuth”)

这是将用户发送到您的网站进行链接的基本OAuth流程。用户将被重定向到您的网站以登录其帐户。登录后,用户同意与Google共享您在服务上的数据。此时,用户的Google帐户和您的服务已链接。

OAuth链接支持授权代码和隐式OAuth流。您的服务必须为隐式流托管一个符合OAuth 2.0的授权终结点,并且在使用授权代码流时必须同时公开授权和令牌交换终结点。

图1 。使用Web OAuth在用户电话上进行帐户链接

基于OAuth的应用翻转链接(“应用翻转”)

OAuth流,将用户发送到您的应用进行链接。

基于OAuth的应用翻转链接可在用户在经过验证的Android或iOS移动应用与Google平台之间移动时引导用户查看建议的数据访问更改,并同意将其平台上的帐户与他们的Google帐户关联起来。要启用App Flip,您的服务必须使用授权代码流支持OAuth链接基于OAuth的Google登录链接

AndroidiOS均支持App Flip。

这个怎么运作:

Google应用会检查您的应用是否已安装在用户的设备上:

  • 如果找到该应用程序,则用户将“翻转”到您的应用程序。您的应用已征得用户的同意,将帐户与Google关联,然后“翻转”回Google表面。
  • 如果未找到应用程序或在应用程序翻转链接过程中发生错误,则将用户重定向到精简流或Web OAuth流。

图2 。带有App Flip的用户手机上的帐户关联

基于OAuth的精简链接(“精简”)

基于OAuth的Google Sign-In Streamlined链接在OAuth链接之上添加了Google Sign-In,使用户能够完成链接过程而不会离开Goog​​le表面,从而减少了摩擦和脱落。通过将Google登录与OAuth链接结合在一起,基于OAuth的精简链接可提供无缝登录,帐户创建和帐户链接的最佳用户体验。您的服务必须支持符合OAuth 2.0的授权和令牌交换端点。此外,您的令牌交换端点必须支持JSON Web令牌(JWT)声明,并实现checkcreateget意图。

这个怎么运作:

Google声明用户帐户并将此信息传递给您:

  • 如果您的数据库中存在该用户的帐户,则该用户成功将其Google帐户与他们在您的服务上的帐户相关联。
  • 如果您的数据库中没有该用户的帐户,则该用户可以使用Google提供的断言信息创建一个新的3P帐户:电子邮件,姓名和个人资料图片,或者选择登录并与其他电子邮件链接(这将要求他们通过Web OAuth登录到您的服务)。

图3 。使用简化的链接在用户电话上进行帐户链接

您应该使用哪个流量?

我们建议实施所有流程,以确保用户获得最佳的链接体验。流线型和App翻转流减少了链接摩擦,因为用户可以在非常少的步骤中完成链接过程。 Web OAuth链接的工作量最低,是一个很好的起点,之后您可以添加其他链接流。

使用令牌

Google帐户链接基于OAuth 2.0行业标准。

在获得帐户持有人同意链接其帐户和共享数据之后,您可以为各个Google帐户向Google发出访问令牌。

代币类型

OAuth 2.0使用称为令牌的字符串在用户代理,客户端应用程序和OAuth 2.0服务器之间进行通信。

帐户链接期间可以使用三种OAuth 2.0令牌:

  • 授权码。可以交换访问权限的短期令牌和刷新令牌。为了安全起见,Google会调用您的授权端点来获取一次性使用或寿命很短的代码。

  • 访问令牌。授予承载者对资源的访问权的令牌。为了限制可能因丢失此令牌而导致的风险敞口,它的使用寿命有限,通常会在一个小时左右后过期。

  • 刷新令牌。访问令牌到期时可以交换新的访问令牌的长期令牌。当您的服务与Google集成时,此令牌将由Google专门存储和使用。 Google调用您的令牌交换端点,以将刷新令牌交换为访问令牌,这些访问令牌又用于访问用户数据。

代币处理

在使用令牌时,群集环境和客户端-服务器交换中的竞争条件可能导致复杂的时序和错误处理方案。例如:

  • 您收到一个新的访问令牌的请求,并发出一个新的访问令牌。同时,您会收到使用前一个未过期的访问令牌访问服务资源的请求。
  • 您的刷新令牌回复尚未被Google收到(或从未收到)。同时,先前有效的刷新令牌用于Google的请求中。

由于在群集中运行的异步服务,网络行为或其他方式,请求和答复可以以任何顺序到达,或者根本无法到达。

无法保证您和Google的令牌处理系统之间以及之间的即时且完全一致的共享状态。多个有效的未过期令牌可以在短时间内在系统内或系统之间共存。为了最大程度地减少对用户的负面影响,建议您执行以下操作:

  • 即使发布了更新的令牌,也要接受未过期的访问令牌。
  • 使用替代方法来刷新令牌轮换
  • 支持多个并发有效的访问和刷新令牌。为了安全起见,应限制令牌的数量和令牌的生存期。
维护和停运处理

在维护或计划外中断期间,Google可能无法调用您的授权或令牌交换端点来获取访问权限并刷新令牌。

您的端点应以503错误代码和空主体作为响应。在这种情况下,Google将在有限的时间内重试失败的令牌交换请求。如果Google以后能够获取刷新和访问令牌,则失败的请求对用户不可见。

如果用户发起访问请求失败的请求,则会导致可见错误。如果使用隐式OAuth 2.0流程,则要求用户重试链接失败。

推荐建议

有许多解决方案可以最大程度地减少维护影响。要考虑的一些选项:

  • 维护您现有的服务,并将有限数量的请求路由到您的新更新的服务。仅在确认预期功能后才能迁移所有请求。

  • 在维护期间减少令牌请求的数量:

    • 将维护周期限制为少于访问令牌生存期。

    • 临时增加访问令牌的生存期:

      1. 将令牌寿命增加到大于维护期限。
      2. 等待两次访问令牌生存期,从而使用户可以将短期令牌替换为较长令牌。
      3. 输入维护。
      4. 使用503错误代码和空主体来响应令牌请求。
      5. 退出维护。
      6. 将令牌生存期降低到正常水平。

向Google注册

我们将需要OAuth 2.0设置的详细信息,并需要共享凭据才能启用帐户链接。有关详细信息,请参见注册