透過 OAuth 連結 Google 帳戶 (隱含流程 - 已封存)

如要支援 OAuth 2.0 隱含流程，您的服務會透過 HTTPS 提供授權端點。這個端點負責驗證，並取得使用者同意授權資料存取權。授權端點會向尚未登入的使用者顯示登入 UI，並記錄對所要求存取權的同意聲明。

當 Google 應用程式需要呼叫您服務的授權 API 時，Google 會使用這個端點取得使用者授權，代表他們呼叫這些 API。

Google 帳戶連結：OAuth 隱含流程

下方的序列圖詳細說明使用者、Google 和服務端點之間的互動。

角色與職責

下表定義 Google 帳戶連結 (GAL) OAuth 隱含流程中參與者的角色和職責。請注意，在 GAL 中，Google 會擔任 OAuth 用戶端，而您的服務則擔任身分/服務供應商。

Google 啟動的一般 OAuth 2.0 隱含流程工作階段如下：

1. Google 會在使用者瀏覽器中開啟授權端點。使用者登入 (如果尚未登入)，並授權 Google 透過您的 API 存取資料 (如果尚未授權)。
2. 您的服務會建立存取權杖，並傳回給 Google。如要這麼做，請將使用者的瀏覽器重新導向回 Google，並在要求中附加存取權杖。
3. Google 會呼叫服務的 API，並在每項要求中附加存取權杖。您的服務會驗證存取權杖是否授予 Google 存取 API 的授權，然後完成 API 呼叫。

導入方案

請按照下列步驟導入隱含流程。

步驟 1：處理授權要求

Google 啟動帳戶連結程序時，會將使用者重新導向至授權端點。如需詳細的通訊協定合約和參數規定，請參閱「授權端點」。

如要處理要求，請執行下列動作：

1. 驗證要求：

   • 確認 client_id 與指派給 Google 的用戶端 ID 相符。
   • 確認 redirect_uri 與預期的 Google 重新導向網址相符： none https://oauth-redirect.googleusercontent.com/r/YOUR_PARTNER_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PARTNER_ID
   • 確認 response_type 為 token。

2. 驗證使用者：

   • 確認使用者是否已登入您的服務。
   • 如果使用者未登入，請提示他們完成登入或註冊流程。

3. 產生存取權杖：

   • 建立與使用者和用戶端相關聯的專屬存取權杖，且權杖內容無法猜測。

4. 重新導向回 Google：

   • 將瀏覽器重新導向至 redirect_uri 中提供的網址。
   • 在網址片段 (雜湊) 中附加下列參數：
     • access_token：您產生的存取權杖。
     • token_type：必須為 bearer。
     • state：從 Google 收到的未修改狀態值。

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.