總覽

帳戶連結功能可讓 Google 帳戶持有人快速、順暢且安全地連結至您的服務。您可以選擇導入 Google 帳戶連結功能，將平台上的使用者資料分享給 Google 應用程式和服務。

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

使用者可以連結或取消連結帳戶，也可以選擇在您的平台上透過 Google 帳戶連結功能建立新帳戶。

用途

導入 Google 帳戶連結功能的部分原因如下：

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

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

• 使用 Google Home 應用程式和 Google 助理管理及控制 Google 智慧家庭連結的裝置，只要說出「Google，開燈」即可。

• 使用對話動作建立使用者自訂的 Google 助理體驗和功能，例如「Ok Google，幫我點星巴克的常點飲料」。

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

• 在註冊期間，使用Google 帳戶個人資料中經過同意共用的資料，預先填入新帳戶。

支援的功能

Google 帳戶連結功能支援下列功能：

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

• 使用 OAuth 連結授權碼流程，提升安全性。

• 讓現有使用者登入您的平台，或讓新使用者透過 Google 驗證註冊，取得使用者的同意，並透過簡化連結安全地分享資料。

• 使用應用程式翻轉功能，提升便利性。只要在可信任的 Google 應用程式中輕輕一按，即可安全地開啟已驗證的 Android 或 iOS 應用程式，並透過一鍵操作取得使用者同意，以及連結帳戶。

• 定義自訂權限範圍，只分享必要資料，提升使用者隱私權，並清楚定義資料的使用方式，提升使用者信任感。

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

注意：Google 身分平台的大部分 OAuth 2.0 說明文件都會說明如何讓使用者透過 Google 帳戶登入，並取得授權，以便代為呼叫 Google API。Google 帳戶連結功能涵蓋相反的情況，也就是允許 Google 服務使用者透過您的平台進行驗證，並呼叫服務的 API。如果您想使用 OAuth 2.0 存取 Google API，請參閱 OAuth 2.0 用戶端說明文件。

帳戶連結流程

有 3 種 Google 帳戶連結流程，全都是以 OAuth 為基礎，需要管理或控制符合 OAuth 2.0 標準的授權和符記交換端點。

在連結過程中，您會先取得帳戶持有人連結帳戶及分享資料的同意聲明，再向 Google 發出個別 Google 帳戶的存取權權杖。

OAuth 連結 (「Web OAuth」)

這是基本 OAuth 流程，會將使用者導向您的網站進行連結。系統會將使用者重新導向至您的網站，讓他們登入帳戶。使用者登入後，就會同意將您服務中的資料提供給 Google。此時，使用者的 Google 帳戶和您的服務就會連結。

OAuth 連結支援授權碼和隱含 OAuth 流程。您的服務必須代管符合 OAuth 2.0 標準的授權端點，以便處理隱含流程，且必須在使用授權碼流程時，同時公開授權和權杖交換端點。

注意： 所有帳戶連結整合作業都必須實作 Web OAuth，因為這是應用程式翻轉和簡化流程的備用方法。

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

以 OAuth 為基礎的應用程式快速連結 (「應用程式快速連結」)

將使用者傳送至應用程式進行連結的 OAuth 流程。

以 OAuth 為基礎的應用程式翻轉連結功能會引導使用者在您已驗證的 Android 或 iOS 行動應用程式和 Google 平台之間移動，以便查看建議的資料存取權變更，並授予同意聲明，將他們在您平台上的帳戶與 Google 帳戶連結。如要啟用「應用程式翻轉」功能，您的服務必須支援 OAuth 連結或使用 授權碼流程的 以 OAuth 為基礎的 Google 登入連結。

Android 和 iOS 都支援應用程式翻轉功能。

運作方式：

Google 應用程式會檢查使用者裝置上是否安裝您的應用程式：

• 如果找到應用程式，系統會將使用者「轉換」至您的應用程式。您的應用程式會向使用者收集同意將帳戶連結至 Google 的資訊，然後「轉換」回 Google 介面。
• 如果在應用程式翻轉連結程序中找不到應用程式，或發生錯誤，系統會將使用者重新導向至簡化或網頁 OAuth 流程。

圖 2. 使用 App Flip 在使用者的手機上連結帳戶

以 OAuth 為基礎的簡化連結 (「簡化」)

以 OAuth 為基礎的 Google 登入功能簡化連結會在 OAuth 連結上方加入 Google 登入功能，讓使用者不必離開 Google 介面，即可完成連結程序，進而減少使用者流失和放棄的情況。以 OAuth 為基礎的簡化連結功能結合了 Google 登入和 OAuth 連結功能，可提供最佳使用者體驗，提供流暢的登入、建立帳戶和帳戶連結功能。您的服務必須支援符合 OAuth 2.0 標準的授權和憑證交換端點。此外，您的權杖交換端點必須支援 JSON Web Token (JWT) 斷言，並實作 check、create 和 get 意圖。

注意： 使用者在這個流程中不會離開 Google 介面，因此 Google 必須代表第三方顯示同意聲明，才能讓流程正常運作。

運作方式：

Google 會驗證使用者帳戶，並將以下資訊傳遞給您：

• 如果資料庫中已有使用者的帳戶，表示使用者已成功將自己的 Google 帳戶連結至貴機構服務中的帳戶。
• 如果資料庫中沒有使用者的帳戶，使用者可以使用 Google 提供的資訊建立新的第三方帳戶，包括電子郵件、姓名和個人資料相片；或者選擇登入並連結其他電子郵件 (這需要使用者透過 Web OAuth 登入您的服務)。

圖 3. 使用簡化連結功能在使用者手機上連結帳戶

您應使用哪個流程？

建議您實作所有流程，確保使用者享有最佳連結體驗。簡化和應用程式翻轉流程可減少連結阻礙，因為使用者只需完成幾個步驟，就能完成連結程序。網頁 OAuth 連結的難度最低，是您開始使用連結流程的好地方，之後再加入其他連結流程。

注意： 所有整合都必須使用 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.

Warning: Do not return a 400 error code and {"error": "invalid_grant"} body during maintenance or outages. Doing so deletes previously issued tokens and requires users to relink their accounts.

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 設定的詳細資料，並分享憑證，才能啟用帳戶連結功能。詳情請參閱註冊。