帳戶連結可讓 Google 帳戶持有人快速且安全地連線至服務。您可以選擇導入 Google 帳戶連結,以便將平台的使用者資料提供給 Google 應用程式和服務。
安全 OAuth 2.0 通訊協定可讓您安全地將使用者的 Google 帳戶連結至其平台上的帳戶,進而授權 Google 應用程式和裝置存取您的服務。
使用者可以連結或取消連結自己的帳戶,也能選擇透過 Google 帳戶連結在您的平台上建立新帳戶。
用途
導入 Google 帳戶連結的幾個可能原因如下:
與 Google 應用程式和服務分享使用者平台中的資料。
使用 Google TV 播放影片和電影內容。
使用 Google Home 應用程式和 Google 助理管理及操控 Google 智慧型住宅已連結的裝置,並說出「Ok Google 開燈」。
使用對話動作功能,為使用者自訂 Google 助理體驗和功能。
允許使用者在 YouTube 上連結獎勵合作夥伴帳戶後,在 YouTube 上觀看符合資格的直播影片,因而獲得獎勵。
申請時,系統會預先使用 Google 帳戶設定檔的共用資料預先填入新帳戶。
支援的功能
Google 帳戶連結支援下列功能:
使用 OAuth 連結隱含流程輕鬆快速分享資料。
使用 OAuth 連結授權碼流程提供更完善的安全性。
登入現有使用者,或為 Google 驗證的新使用者完成登入平台的程序,取得使用者的同意聲明,並透過簡化連結安全共用資料。
使用應用程式翻轉功能減少便利性。在信任的 Google 應用程式中,輕觸一下就能安全開啟已驗證的 Android 或 iOS 應用程式,而輕觸一下就能為使用者提供同意授權,並連結帳戶。
藉由定義自訂範圍來僅分享必要資料來提升使用者隱私,並明確定義資料的使用方式,藉此提升使用者信任感。
透過「取消連結」帳戶即可撤銷對平台上代管的資料和服務的存取權。實作選用的權杖撤銷端點可讓您與 Google 啟動的事件保持同步,而跨帳戶防護功能 (RISC) 則可讓您在 Google 平台上發生任何取消連結事件時通知 Google。
帳戶連結流程
有 3 個 Google 帳戶連結流程均以 OAuth 為基礎,並需要您管理或控制與 OAuth 2.0 相容的授權和權杖交換端點。
在連結過程中,如果帳戶擁有者同意連結其帳戶並分享資料,您要向 Google 核發個別應用程式的存取權杖,
OAuth 連結 ('網路 OAuth')
這是基本 OAuth 流程,可將使用者帶往您的網站進行連結。系統會將使用者重新導向至您的網站,以登入自己的帳戶。登入後,使用者同意將您的服務資料提供給 Google。此時,使用者的 Google 帳戶和您的服務就會建立連結。
OAuth 連結支援授權碼和隱含 OAuth 流程。您的服務必須代管隱含流程且符合 OAuth 2.0 的授權端點,且在使用授權碼流程時,您必須公開授權和權杖交換端點。

圖 1. 使用者的手機透過網路 OAuth 連結帳戶
OAuth 型應用程式翻轉連結 ('應用程式翻轉')
可將使用者導向應用程式進行連結的 OAuth 流程。
以 OAuth 為基礎的應用程式翻轉連結功能會在使用者完成已驗證的 Android 或 iOS 行動應用程式與 Google 平台間切換,引導使用者查看提議的資料存取權異動,並授權將您的平台帳戶連結至其 Google 帳戶。如要啟用應用程式翻轉功能,您的服務必須使用授權碼流程支援 OAuth 連結或以 OAuth 為基礎的 Google 登入連結。
Android 裝置和 iOS 應用程式皆支援應用程式翻轉功能。
運作方式:
Google 應用程式會檢查使用者的裝置是否已安裝您的應用程式:
- 找到應用程式後,使用者就會「翻轉」到您的應用程式。應用程式必須徵得使用者同意,才能將帳戶連結至 Google,接著才「返回」#39;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 提供的聲明資訊建立新的第三方帳戶:電子郵件、姓名和個人資料相片,或是選擇登入及連結其他電子郵件 (這會需要透過網路 OAuth 登入服務)。

圖 3. 使用者可透過簡化連結的方式在手機上連結自己的帳戶
這時應該採用哪種流程?
建議您導入所有流程,確保使用者享有最佳連結體驗。簡化的應用程式和應用程式翻轉流程可簡化連結程序,因為使用者只需幾個步驟就能完成連結程序。網頁 OAuth 連結最容易,也是很好的起點,您可以將其加入其他連結流程。
使用權杖
Google Account 是以 OAuth 2.0 業界標準為依據,
獲得帳戶擁有者同意連結其帳戶與分享資料後,您就能為個別 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:
- Increase token lifetime to greater than maintenance period.
- Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
- Enter maintenance.
- Respond to token requests with a
503
error code and empty body. - Exit maintenance.
- Decrease token lifetime back to normal.
註冊 Google
我們需要您提供 OAuth 2.0 設定的詳細資料,並分享憑證才能啟用 帳戶連結。詳情請參閱「註冊」。