選擇整合路徑
請選取最符合需求的途徑：
| 路徑 | 適用情境 | 瞭解詳情 |
|---|---|---|
| 通用商務通訊協定 (UCP) | 商家和零售商。 | UCP 文件 |
| 標準帳戶連結 | 智慧型住宅、電視和 YouTube。 | 文件 |
帳戶連結功能可讓 Google 帳戶持有人快速、順暢且安全地連結至您的服務。您可以選擇實作 Google 帳戶連結，將平台上的使用者資料分享給 Google 應用程式和服務。
透過安全的 OAuth 2.0 通訊協定，您可以將使用者的 Google 帳戶安全地連結至平台上的帳戶，進而授權 Google 應用程式和裝置存取您的服務。
使用者可以連結或取消連結帳戶，也可以選擇在您的平台上透過 Google 帳戶連結功能建立新帳戶。
用途
實作 Google 帳戶連結的原因包括：
與 Google 應用程式和服務共用平台上的使用者資料。
使用通用商務通訊協定 (UCP)，與 Google 購物和 AI 平台 (搜尋、Gemini) 整合。
使用 Google TV 播放影片和電影內容。
使用 Google Home 應用程式和 Google 助理管理及控制已連結的Google 智慧住宅裝置，例如說出「Ok Google，開燈」。
透過對話動作建立使用者自訂的 Google 助理體驗和功能，例如「Ok Google，幫我向星巴克訂購平常的餐點」。
使用者將 Google 帳戶連結至獎勵合作夥伴帳戶後，只要在 YouTube 觀看符合資格的直播，就有機會獲得獎勵。
在註冊期間，使用Google 帳戶個人資料中經使用者同意分享的資料，預先填入新帳戶。
功能與需求
下表定義了每個連結流程的支援和建議。
| 連結流程 | 標準功能 | UCP 功能 |
|---|---|---|
| App Flip | 建議 | 建議 |
| 簡化連結程序 | 建議 | 建議 |
| OAuth 連結 | 必要 (備用廣告) | 必要 (備用廣告) |
| OAuth 2.1 | 建議 | 建議 |
定義自訂範圍，只分享必要資料，提升使用者隱私權；清楚定義資料使用方式，提高使用者信任感。
如要撤銷存取權，請取消連結帳戶。導入選用的權杖撤銷端點，可讓您與 Google 發起的事件保持同步，而跨帳戶保護(RISC) 則可讓您將平台發生的任何取消連結事件通知 Google。
帳戶連結流程
共有 3 種 Google 帳戶連結流程，全都是以 OAuth 為基礎，且需要您管理或控管符合 OAuth 2.0 規範的授權和符記交換端點。
在連結過程中，您必須先取得帳戶擁有者的同意，允許連結帳戶並共用資料，然後再為個別 Google 帳戶向 Google 核發存取權杖。
OAuth 連結
這是 OAuth 連結流程，可將使用者帶往您的網站進行連結。使用者會重新導向至您的網站，登入自己的帳戶。 登入後，使用者會同意將服務中的資料分享給 Google。此時，使用者的 Google 帳戶和您的服務會連結在一起。
OAuth 連結支援授權碼和隱含 OAuth 流程。您的服務必須代管符合 OAuth 2.0 規範的授權端點，以供隱含流程使用，並在使用授權碼流程時，公開授權和權杖交換端點。
圖 1. 使用者手機上的帳戶連結 (透過 OAuth 連結)
以 OAuth 為基礎的應用程式快速連結 (「應用程式快速連結」)
OAuth 流程，可將使用者帶往應用程式進行連結。
以 OAuth 為基礎的應用程式快速連結功能會引導使用者在已驗證的 Android 或 iOS 行動應用程式與 Google 平台之間切換，以便查看建議的資料存取權變更，並同意將平台上的帳戶連結至 Google 帳戶。如要啟用應用程式快速連結功能，服務必須支援 OAuth 連結或以 OAuth 為基礎的「使用 Google 帳戶登入」，並使用授權碼流程。
運作方式：
Google 應用程式會檢查使用者裝置是否已安裝您的應用程式：
- 如果找到應用程式，系統會「翻轉」至您的應用程式。您的應用程式會徵求使用者同意將帳戶連結至 Google，然後「翻轉返回」Google 介面。
- 如果找不到應用程式，或在應用程式快速連結程序中發生錯誤，使用者會重新導向至簡化或 OAuth 連結流程。
圖 2. 在使用者手機上透過應用程式切換功能連結帳戶
以 OAuth 為基礎的簡化連結 (簡稱「簡化」)
以 OAuth 為基礎的「使用 Google 帳戶登入」簡化連結功能，會在 OAuth 連結的基礎上新增「使用 Google 帳戶登入」功能，讓使用者不必離開 Google 服務即可完成連結程序，減少阻礙和流失。以 OAuth 為基礎的簡化連結結合了「使用 Google 帳戶登入」和 OAuth 連結功能，提供最佳使用者體驗，讓使用者能順暢登入、建立及連結帳戶。您的服務必須支援符合 OAuth 2.0 規範的授權和權杖交換端點。此外，權杖交換端點必須支援 JSON Web Token (JWT) 聲明，並實作 check、create 和 get 意圖。
運作方式：
Google 會驗證使用者帳戶，並將這項資訊傳遞給您：
- 如果資料庫中已有該使用者的帳戶，使用者就能順利將 Google 帳戶連結至服務中的帳戶。
- 如果資料庫中沒有使用者的帳戶，使用者可以選擇使用 Google 提供的聲明資訊 (電子郵件地址、姓名和個人資料相片) 建立新的第三方帳戶，也可以選擇登入並連結至其他電子郵件地址 (這需要使用 OAuth 連結登入服務)。
圖 3. 在使用者手機上透過簡化連結功能連結帳戶
您應該使用哪個流程？
建議您導入所有流程，確保使用者獲得最佳的連結體驗。簡化和應用程式快速連結流程可減少連結障礙，使用者只需幾個步驟即可完成連結過程。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 流程，使用者必須重試連結失敗的帳戶。
建議
有多種解決方案可將維護作業的影響降到最低。可考慮的選項：
維持現有服務，並將有限數量的要求傳送至新更新的服務。確認功能符合預期後，再遷移所有要求。
在維護期間減少權杖要求數量：
將維護期限制在存取權杖生命週期內。
暫時延長存取權杖的生命週期：
- 將權杖生命週期延長至維護期以上。
- 等待時間應為存取權杖效期的兩倍，讓使用者能將短期權杖換成效期較長的權杖。
- 輸入維護作業。
- 以
503錯誤代碼和空白主體回應權杖要求。 - 結束維護作業。
- 將權杖生命週期縮短至正常時間。
永久連結
如要確保整合作業穩定運作，必須使用持續性連結。即使發生暫時性網路故障或定期重新整理憑證，使用者帳戶仍會保持連結。
如要實作持續性連結，請使用「滑動視窗」方法：延長現有重新整理權杖的到期時間，而非輪替權杖 (請參閱 RFC 6749 第 6 節)。這樣可避免發生競爭條件和非預期的取消連結，因為如果系統發出新的更新權杖，但 Google 未成功接收或儲存，就可能發生這類情況。
使用 Google 帳戶註冊
我們需要 OAuth 2.0 設定的詳細資料，並分享憑證來啟用帳戶連結。詳情請參閱註冊。