概述

帐户关联使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发出访问令牌。

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

  • Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.

  • Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.

  • Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

  • You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
  • Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

  • Accept unexpired access tokens, even after a newer token is issued.
  • Use alternatives to Refresh Token Rotation.
  • Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.
Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

  • Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.

  • Reduce the number of token requests during the maintenance period:

    • Limit maintenance periods to less than the access token lifetime.

    • Temporarily increase the access token lifetime:

      1. Increase token lifetime to greater than maintenance period.
      2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
      3. Enter maintenance.
      4. Respond to token requests with a 503 error code and empty body.
      5. Exit maintenance.
      6. Decrease token lifetime back to normal.

向Google注册

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