使用 OAuth 連結 Google 帳戶

帳戶是透過業界標準的 OAuth 2.0 授權碼流程連結。

代理程式適用的 OAuth 2.1 和 PKCE

對於無狀態 AI 代理程式和多模態管道，建議強制執行 OAuth 2.1。

• PKCE (用於程式碼交換的金鑰證明)：必須用於保護授權碼流程，防止攔截攻擊。
• 沒有隱含流程：隱含流程會在網址中公開存取權杖， 這會對代理程式環境造成安全風險。

您的服務必須支援符合 OAuth 2.0/2.1 規範的授權和權杖交換端點。

注意：隱含流程已淘汰，不再支援新的整合。如果您要維護現有的隱含流程整合，請參閱 [已封存的隱含流程](/identity/account-linking/archive/implicit-flow)說明文件。

Create the project

Note: You can reuse an existing project and do not need to create a new project primarily for account linking.

To create your project to use account linking:

1. Go to the Google API Console.
2. Click Create project.
3. Enter a name or accept the generated suggestion.
4. Confirm or edit any remaining fields.
5. Click Create.

To view your project ID:

1. Go to the Google API Console.
2. Find your project in the table on the landing page. The project ID appears in the ID column.

Configure your OAuth Consent Screen

The Google Account Linking process includes a consent screen which tells users the application requesting access to their data, what kind of data they are asking for and the terms that apply. You will need to configure your OAuth consent screen before generating a Google API client ID.

1. Open the OAuth consent screen page of the Google APIs console.
2. If prompted, select the project you just created.

3. On the "OAuth consent screen" page, fill out the form and click the “Save” button.

   Application name: The name of the application asking for consent. The name should accurately reflect your application and be consistent with the application name users see elsewhere. The application name will be shown on the Account Linking consent screen.

   Application logo: An image on the consent screen that will help users recognize your app. The logo is shown on Account linking consent screen and on account settings

   Support email: For users to contact you with questions about their consent.

   Scopes for Google APIs: Scopes allow your application to access your user's private Google data. For the Google Account Linking use case, default scope (email, profile, openid) is sufficient, you don’t need to add any sensitive scopes. It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. Learn more.

   Authorized domains: To protect you and your users, Google only allows applications that authenticate using OAuth to use Authorized Domains. Your applications' links must be hosted on Authorized Domains. Learn more.

   Application Homepage link: Home page for your application. Must be hosted on an Authorized Domain.

   Application Privacy Policy link: Shown on Google Account Linking consent screen. Must be hosted on an Authorized Domain.

   Application Terms of Service link (Optional): Must be hosted on an Authorized Domain.

   

   Figure 1. Google Account Linking Consent Screen for a fictitious Application, Tunery

4. Check "Verification Status", if your application needs verification then click the "Submit For Verification" button to submit your application for verification. Refer to OAuth verification requirements for details.

導入 OAuth 伺服器

An OAuth 2.0 server implementation of the authorization code flow consists of two endpoints, which your service makes available by HTTPS. The first endpoint is the authorization endpoint, which is responsible for finding or obtaining consent from users for data access. The authorization endpoint presents a sign-in UI to your users that aren't already signed in and records consent to the requested access. The second endpoint is the token exchange endpoint, which is used to obtain encrypted strings, called tokens, that authorize a user to access your service.

When a Google application needs to call one of your service's APIs, Google uses these endpoints together to get permission from your users to call these APIs on their behalf.

Google Account Linking: OAuth Authorization Code Flow

The following sequence diagram details interactions between the User, Google, and your service's endpoints.

Figure 1. The sequence of events in the OAuth 2.0 Authorization Code flow for Google Account Linking.

Roles and responsibilities

The following table defines the roles and responsibilities of the actors in the Google Account Linking (GAL) OAuth flow. Note that in GAL, Google acts as the OAuth Client, while your service acts as the Identity/Service Provider.

Actor / Component	GAL Role	Responsibilities
Google App / Server	OAuth Client	Initiates the flow, receives the authorization code, exchanges it for tokens, and securely stores them to access your service's APIs.
Your Authorization Endpoint	Authorization Server	Authenticates your users and obtains their consent to share access to their data with Google.
Your Token Exchange Endpoint	Authorization Server	Validates authorization codes and refresh tokens, and issues access tokens to the Google Server.
Google Redirect URI	Callback Endpoint	Receives the user redirect from your authorization service with the code and state values.

An OAuth 2.0 authorization code flow session initiated by Google has the following flow:

1. Google opens your authorization endpoint in the user's browser. If the flow started on a voice-only device for an Action, Google transfers the execution to a phone.
2. The user signs in, if not signed in already, and grants Google permission to access their data with your API, if they haven't already granted permission.
3. Your service creates an authorization code and returns it to Google. To do so, redirect the user's browser back to Google with the authorization code attached to the request.
4. Google sends the authorization code to your token exchange endpoint, which verifies the authenticity of the code and returns an access token and a refresh token. The access token is a short-lived token that your service accepts as credentials to access APIs. The refresh token is a long-lived token that Google can store and use to acquire new access tokens when they expire.
5. After the user has completed the account linking flow, every subsequent request sent from Google contains an access token.

Implementation Recipe

Follow these steps to implement the Authorization Code flow.

Step 1: Handle authorization requests

When Google initiates account linking, it redirects the user to your authorization endpoint. For detailed protocol contracts and parameter requirements, see the Authorization Endpoint.

To handle the request, perform the following actions:

1. Validate the request:

   • Confirm that the client_id matches the Client ID assigned to Google.
   • Confirm that the redirect_uri matches the expected Google redirect URL: none https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
   • Verify that response_type is code.

2. Authenticate the user:

   • Check if the user is signed in to your service.
   • If the user is not signed in, prompt them to complete your sign-in or sign-up flow.

3. Generate authorization code:

   • Create a unique, non-guessable authorization code associated with the user and client.
   • Set the code to expire in approximately 10 minutes.

4. Redirect back to Google:

   • Redirect the browser to the URL provided in redirect_uri.
   • Append the following query parameters:
     • code: The authorization code you generated.
     • state: The unmodified state value received from Google.

Step 2: Handle token exchange requests

Your token exchange endpoint processes two types of requests: exchanging codes for tokens, and refreshing expired access tokens. For detailed protocol contracts and parameter requirements, see the Token Exchange Endpoint.

A. Exchange authorization codes for tokens

When Google receives the authorization code, it calls your token exchange endpoint (POST) to retrieve tokens.

1. Validate the request:

   • Verify client_id and client_secret.
   • Verify the authorization code is valid and not expired.
   • Confirm redirect_uri matches the value used in Step 1.
   • If validation fails, return an HTTP 400 Bad Request with {"error": "invalid_grant"}.

2. Issue tokens:

   • Generate a long-lived refresh_token and a short-lived access_token (typically 1 hour).
   • Return an HTTP 200 OK with the standard JSON token response.

B. Refresh access tokens

When the access token expires, Google requests a new one using the refresh token.

1. Validate the request:

   • Verify client_id, client_secret, and refresh_token.
   • If validation fails, return an HTTP 400 Bad Request with {"error": "invalid_grant"}.

2. Issue new access token:

   • Generate a new short-lived access_token.
   • Return an HTTP 200 OK with the JSON token response (optionally including a new refresh token).

處理使用者資訊要求

userinfo 端點是 OAuth 2.0 受保護的資源，可傳回已連結使用者的聲明。除了下列用途外，不一定要實作並代管 userinfo 端點：

• 使用 Google One Tap 登入已連結帳戶。
• 在 AndroidTV 上順暢訂閱。

成功從權杖端點擷取存取權杖後，Google 會向您的使用者資訊端點傳送要求，以擷取已連結使用者的基本個人資料。

userinfo 端點要求標頭
Authorization header	Bearer 類型的存取權杖。

舉例來說，如果您的 userinfo 端點位於 https://myservice.example.com/userinfo，要求可能如下所示：

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

為了讓 userinfo 端點處理要求，請按照下列步驟操作：

1. 從授權標頭擷取存取權杖，然後為與存取權杖相關聯的使用者傳回資訊。
2. 如果存取權杖無效，請使用 WWW-Authenticate 回應標頭傳回 HTTP 401 Unauthorized 錯誤。以下是 userinfo 錯誤回應的範例：

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

   敬上 如果連結過程中傳回 401 未授權錯誤或其他失敗錯誤回應，將無法復原錯誤，擷取到的憑證將遭到捨棄，使用者必須再次啟動連結程序。

3. 如果存取權杖有效，則傳回並傳回 HTTP 200 回應，且 HTTPS 內文含有下列 JSON 物件 回應：

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

   敬上 如果您的 userinfo 端點傳回 HTTP 200 成功回應，則會根據使用者的 Google 帳戶登錄擷取的權杖和憑證附加資訊。

   userinfo 端點回應
   sub	用來在系統中識別使用者的專屬 ID。
   email	使用者的電子郵件地址。
   given_name	選填：使用者的名字。
   family_name	選填：使用者的姓氏。
   name	選填：使用者全名。
   picture	選用：使用者的個人資料相片。

驗證實作

您可以使用 OAuth 2.0 Playground 工具驗證實作成果。

在工具中執行下列步驟：

1. 點選「設定」 開啟「OAuth 2.0 設定」視窗。
2. 在「OAuth flow」欄位中，選取「用戶端」。
3. 在「OAuth Endpoints」(OAuth 端點) 欄位中，選取「Custom」(自訂)。
4. 在對應欄位中，指定 OAuth 2.0 端點和您指派給 Google 的用戶端 ID。
5. 在「步驟 1」部分，請勿選取任何 Google 範圍。請將這個欄位留空，或輸入適用於伺服器的範圍 (如果您未使用 OAuth 範圍，則輸入任意字串)。完成後，請按一下「授權 API」。
6. 在「步驟 2」和「步驟 3」部分，請完成 OAuth 2.0 流程，並確認每個步驟都能正常運作。

您可以使用 Google 帳戶連結示範工具驗證實作項目。

在工具中執行下列步驟：

1. 按一下「使用 Google 帳戶登入」按鈕。
2. 選擇要連結的帳戶。
3. 輸入服務 ID。
4. 選擇性輸入您要要求存取的一或多個範圍。
5. 按一下「開始試用」。
6. 系統顯示提示時，確認您要同意或拒絕連結要求。
7. 確認系統會將你重新導向至平台。