帳戶關聯使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登錄鏈接。
這個怎麼運作：
Google應用會檢查您的應用是否已安裝在用戶的設備上：
- 如果找到該應用程序，則用戶將“翻轉”到您的應用程序。您的應用已徵得用戶的同意，將帳戶與Google關聯，然後“翻轉”回Google表面。
- 如果未找到應用程序或在應用程序翻轉鏈接過程中發生錯誤，則將用戶重定向到精簡流或Web OAuth流。
圖2 。帶有App Flip的用戶手機上的帳戶關聯
基於OAuth的精簡鏈接（“精簡”）
基於OAuth的Google Sign-In Streamlined鏈接在OAuth鏈接之上添加了Google Sign-In，使用戶能夠完成鏈接過程而不會離開Google表面，從而減少了摩擦和脫落。通過將Google登錄與OAuth鏈接結合在一起，基於OAuth的精簡鏈接可提供無縫登錄，帳戶創建和帳戶鏈接的最佳用戶體驗。您的服務必須支持符合OAuth 2.0的授權和令牌交換端點。此外，您的令牌交換端點必須支持JSON Web令牌（JWT）聲明，並實現check ， create和get意圖。
這個怎麼運作：
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流程，則要求用戶重試鏈接失敗。
推薦建議
有許多解決方案可以最大程度地減少維護影響。要考慮的一些選項：
維護您現有的服務，並將有限數量的請求路由到您的新更新的服務。僅在確認期望的功能之後，遷移所有請求。
在維護期間減少令牌請求的數量：
將維護週期限制為少於訪問令牌生存期。
臨時增加訪問令牌的生存期：
- 將令牌壽命增加到大於維護期限。
- 等待兩次訪問令牌生存期，從而使用戶可以將短期令牌替換為較長令牌。
- 輸入維護。
- 使用
503錯誤代碼和空主體來響應令牌請求。 - 退出維護。
- 將令牌生存期減少到正常水平。
向Google註冊
我們將需要OAuth 2.0設置的詳細信息，並需要共享憑據才能啟用帳戶鏈接。有關詳細信息，請參見註冊。