總覽

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

帳戶連結後,Google 帳戶持有人就能快速安全地流暢地連結至您的服務。您可以選擇導入 Google 帳戶連結, 將您 Google Analytics (分析) 中的使用者資料與您的平台共用。

安全 OAuth 2.0 通訊協定可讓您安全地將使用者的 Google 帳戶與其平台上的帳戶連結,進而授權 Google 應用程式和裝置存取您的服務。

使用者可透過「Google 帳戶連結」在您的平台上連結帳戶或取消連結,並視需要建立新帳戶。

用途

導入「Google 帳戶連結」的幾個可能原因如下:

  • 將平台上的使用者資料提供給 Google 應用程式和服務。

  • 使用 Google TV 播放影片和電影內容。

  • 透過 Google Home 應用程式和 Google 助理管理和控制 Google 智慧型住宅已連結的裝置,然後說出「Ok Google 開燈」。

  • 運用對話動作,為使用者建立自訂 Google 助理體驗和功能。 「Ok Google,依照星巴克訂購我平常的訂購商品。」

  • 將使用者的 Google 帳戶連結至獎勵合作夥伴帳戶後,在 YouTube 上觀看符合資格的直播影片,就能獲得獎勵。

  • 在申請過程中,使用 Google 帳戶設定檔中預先提供的共用資料預先填入新帳戶。

支援的功能

「Google 帳戶連結」支援下列功能:

  • 使用 OAuth 連結隱含流程輕鬆快速地共用資料。

  • 透過 OAuth 連結授權碼提供更完善的安全防護。

  • 透過簡化連結功能,登入現有使用者或註冊新的 Google 已驗證使用者、取得其同意聲明,並以安全的方式分享資料。

  • 善用應用程式翻轉功能,讓操作流程更順暢。只要在信任的 Google 應用程式中,輕觸一下就能安全地開啟經過驗證的 Android 或 iOS 應用程式,輕觸一下即可授權使用者並連結帳戶。

  • 定義自訂範圍僅分享必要的資料,藉此提升使用者隱私;明確定義資料的使用方式,提高使用者的信任感。

  • 您可以取消連結帳戶,撤銷您在平台上託管的資料和服務存取權。實作選用的憑證撤銷端點可讓您與 Google 啟動的事件保持同步,而跨帳戶防護功能(RISC) 則能讓 Google 通知您的平台發生任何取消連結事件。

帳戶連結流程

「Google 帳戶連結」流程有 3 個採用 OAuth 技術,且需要您管理或控制符合 OAuth 2.0 規定的授權和憑證交換端點。

連結程序中,您必須先取得帳戶持有人同意,連結帳戶並分享資料,才能向 Google 核發個別 Google 帳戶的存取憑證。

OAuth 連結 ('Web OAuth')

這是會將使用者傳送到您網站的基本 OAuth 流程。系統會將使用者重新導向至您的網站,以登入自己的帳戶。使用者登入後,您同意在 Google 服務中將您的資料提供給 Google。此時,使用者的 Google 帳戶和您的服務就已完成連結。

OAuth 連結支援授權碼與隱含式 OAuth 流程。您的服務必須針對隱含流程託管符合 OAuth 2.0 規定的授權端點,並且在使用授權碼流程時同時提供授權與憑證交換端點。

圖 1. 透過 Web OAuth 在使用者的手機上進行帳戶連結

以 OAuth 為基礎的應用程式翻轉連結 ('App Flip')

OAuth 流程會將使用者帶往您的應用程式進行連結。

以 OAuth 為基礎的 App Flip 連結會引導使用者在已驗證的 Android 或 iOS 行動應用程式與 Google 平台之間移動,藉此查看提議的資料存取權變更,並授權使用者在您的平台上將他們的帳戶與 Google 帳戶建立連結。如要啟用 App Flip,您的服務必須支援使用 OAuth 連結OAuth 型 Google 登入連結的方式,使用授權碼流程。

Android 裝置iOS 裝置皆支援應用程式翻轉功能。

運作方式:

Google app 會檢查使用者的裝置是否已安裝該應用程式:

  • 找到應用程式後,使用者就會「翻轉」您的應用程式。應用程式須先徵得使用者同意,才能將帳戶與 Google 建立連結,再恢復成 Google 介面。
  • 如果找不到應用程式,或者應用程式啟動程序發生錯誤,就會發生錯誤。系統會將使用者重新導向至「簡化版」或「網路 OAuth」。

圖 2. 透過應用程式 Flip 將使用者的帳戶連結到使用者的帳戶

OAuth 式精簡連結 ('精簡)

以 OAuth 為基礎的 Google 登入簡化連結:在 OAuth 連結之外,還加入了 Google 登入功能,使用者不需離開 Google 介面,就能完成連結程序,因此可以簡化連結程序和放棄程序。以 OAuth 為基礎的精簡連結:藉由將 Google 登入與 OAuth 連結搭配使用,就能提供順暢的登入體驗、建立帳戶及連結帳戶,為使用者提供最佳體驗。您的服務必須支援符合 OAuth 2.0 規定的授權和憑證交換端點。此外,您的權杖交換端點必須支援 JSON Web Token (JWT) 宣告,並實作 checkcreateget 意圖。

運作方式:

Google 聲明使用者帳戶的擁有權,並將以下資訊傳送給您:

  • 如果您的資料庫中已有使用者的帳戶,則該使用者已成功將您的 Google 帳戶與您的帳戶連結。
  • 如果您的資料庫中沒有使用者的帳戶,使用者便可使用 Google 提供的聲明資訊建立新的第三方帳戶:電子郵件、姓名和個人資料相片,或選擇登入另一個電子郵件地址並建立連結 (使用者必須透過 Web OAuth 登入該服務)。

圖 3. 使用者可透過帳戶連結,在使用者的手機上進行帳戶連結

這時該使用哪個流程?

建議您導入所有流程,確保使用者享有最佳的連結體驗。簡化的應用程式和應用程式翻轉流程可降低連結阻礙,因為使用者只需執行幾個步驟,就能完成連結程序。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 設定詳情,並提供憑證以啟用帳戶連結功能。詳情請參閱註冊一文。