對話動作已於 2023 年 6 月 13 日淘汰。詳情請參閱「
對話動作已淘汰」。
選擇帳戶連結類型
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
最適合動作的帳戶連結類型是能為使用者提供最流暢的體驗，並滿足應用程式或業務需求。選擇連結類型大多取決於下列因素：
- 是否允許透過語音建立帳戶
- 指定使用者是否可以使用非 Google 帳戶登入您的服務
- 您的服務是否可儲存機密資訊 (例如用戶端密鑰)
如要找出理想的帳戶連結類型，請按照下列步驟操作：
- 請參考「找出您偏好的登入類型」一節的問題。
- 請參閱決策樹狀圖，瞭解如何選擇連結類型。
- 請根據您選擇的初始類型，前往相應的章節，進一步修改運作方式。
確定偏好的登入類型
使用決策樹狀圖之前，請先考慮下列問題：
- 您是否預期所有使用者都擁有 Google 帳戶？
- 如果您的動作僅指定 Google 助理，應該所有使用者都擁有 Google 帳戶。如果動作指定的平台是 Google 助理以外的平台，就無法預期所有使用者都擁有 Google 帳戶。
- 如果您的服務已有人使用，可能是因為有些使用者沒有 Google 帳戶，或是未使用 Google 帳戶登入您的服務。
- 如果您採用 OAuth 實作，可以擴大支援 Google 通訊協定嗎？
- 如要支援 Google 通訊協定，您必須在權杖交換端點中加入
intent=get 和 intent=create 功能。這項功能可讓 Google 檢查使用者是否已在您的後端中，並分別提出在您的服務中建立新帳戶的要求。
請按照下方決策樹狀圖，找出最適合您和使用者的帳戶連結類型：
選取連結類型後，請繼續參閱下方對應章節進一步瞭解運作方式，並進一步決定帳戶連結在動作中的運作方式。
以 OAuth 為基礎的 Google 登入「簡便」連結
簡化連結類型除了會使用 OAuth 帳戶連結以外，還會加入 Google 登入 (GSI)，享有 GSI 的優勢 (例如 Google 使用者的語音連結連結)，並為透過非 Google 帳戶註冊您服務的使用者啟用帳戶連結功能。這個連結類型對使用者而言特別實用，因為對於非 Google 使用者而言，這是順暢無礙的流程。如要進一步瞭解簡化連結的運作方式，請參閱 OAuth 式 Google 登入「簡易」連結概念指南。
修正 OAuth 式 Google 登入「簡便」連結類型
在動作中使用簡化連結類型時，您可以在動作主控台中指定下列問題的答案，藉此定義運作方式：
您要啟用語音帳戶的建立功能，還是只允許網站建立帳戶？
一般來說，您應啟用透過語音建立帳戶的功能，讓螢幕不受螢幕裝置的使用者可以建立帳戶，不必轉移至其他裝置。如果您不允許透過語音建立帳戶，Google 助理會開啟您用於使用者驗證的網站網址，並將使用者導向手機以繼續進行帳戶連結流程。
不過，如果符合下列任一情況，請勿允許透過語音建立帳戶：
- 您需要完整控管帳戶建立流程。例如，您可能需要在建立帳戶或傳送其他類型的通知時，向使用者顯示服務條款。
- 您想確保已使用該帳戶登入的使用者。舉例來說，如果您提供會員方案，不希望使用者失去在帳戶中累積的點數，您可能會希望使用者繼續使用現有帳戶。
要使用授權碼流程或隱含流程嗎？
授權碼流程和隱含流程的不同在於，授權碼流程需要第二個端點，也就是「權杖交換」端點。此端點會使用重新整理權杖來產生新的短期存取權杖，而不必提示使用者再次登入。
反之，如果您使用隱性流程，則會將長期存取權杖傳回給 Google，通常不需要重新產生存取權杖。如要進一步瞭解授權碼和隱含流程，請參閱 OAuth 式 Google 登入「簡易」連結概念指南。
Google 建議您在動作中使用授權碼流程，因為這種流程比較安全。不過，如果您的服務無法儲存機密資訊 (即用戶端密鑰)，請改用隱含流程。例如，您必須為公開用戶端 (例如單頁應用程式 (SPA)) 使用隱含流程。
考量這些決策點後，請參照以下決策樹狀圖：
Google 登入
使用 Google 登入 (GSI) 連結類型時，您的動作可在對話期間要求存取使用者的 Google 設定檔，並使用該設定檔資訊來檢查服務後端中是否有使用者。如果使用者不存在，可以在系統中使用他們的 Google 個人資料資訊建立新帳戶。
針對 GSI，您必須透過語音啟用帳戶建立功能，讓使用者可透過語音完成整個流程。如要進一步瞭解 GSI，請參閱 Google 登入概念指南。
OAuth 連結
使用者啟用 OAuth 連結類型後，透過標準 OAuth 2.0 流程登入。OAuth 連結類型支援兩種業界標準 OAuth 2.0 流程：隱含和授權程式碼流程。
Google 不建議使用 OAuth 連結類型，因為當使用者使用非螢幕裝置時，必須將使用者從語音轉移至畫面才能完成登入程序。如果您目前已實作 OAuth 2.0 伺服器，且無法擴充權杖交換端點，也無法透過 ID 權杖新增 Google 通訊協定，以便透過 ID 權杖建立帳戶，則可考慮採用此流程。詳情請參閱 OAuth 連結概念指南。
改善流程
在動作中使用 OAuth 連結類型時，您必須在動作主控台中指定下列問題的答案，才能定義其運作方式：
要使用授權碼流程或隱含流程嗎？
OAuth 連結類型支援兩種業界標準 OAuth 2.0 流程：隱含和授權程式碼流程。授權碼流程和隱含流程的不同在於，授權碼流程需要使用第二個端點，也就是「權杖交換」端點。這個端點會使用重新整理權杖來產生新的短期存取權杖，而不必提示使用者再次登入。
反之，如果您使用隱性流程，則會將長期存取權杖傳回給 Google，通常不需要重新產生存取權杖。如要進一步瞭解授權碼和隱含流程，請參閱 OAuth 連結概念指南。
Google 建議您在動作中使用授權碼流程，因為這種流程比較安全。不過，如果您的服務無法儲存機密資訊 (即用戶端密鑰)，請改用隱含流程。例如，您必須為公開用戶端 (例如單頁應用程式 (SPA)) 使用隱含流程。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2025-07-25 (世界標準時間)。
[null,null,["上次更新時間：2025-07-25 (世界標準時間)。"],[[["\u003cp\u003eThe optimal account linking type for your Google Action depends on user experience, whether you allow voice account creation, accept non-Google accounts, and if your service can handle confidential information.\u003c/p\u003e\n"],["\u003cp\u003eA decision tree helps you determine the best account linking type: OAuth-based Google Sign-in "Streamlined", Google Sign-in, or standard OAuth linking.\u003c/p\u003e\n"],["\u003cp\u003eStreamlined linking combines Google Sign-in benefits with support for non-Google accounts, offering flexibility and a smooth user experience.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Sign-in allows voice account creation and leverages users' Google profiles but may not be ideal if you require extensive control over the account creation process.\u003c/p\u003e\n"],["\u003cp\u003eStandard OAuth linking, while functional, might necessitate switching between voice and screen, potentially hindering user experience.\u003c/p\u003e\n"]]],["Account linking type selection depends on voice account creation, non-Google sign-in, and secure storage capabilities. To choose, consider if users have Google accounts and if existing OAuth can support Google protocol. Streamlined linking combines Google Sign-In (GSI) with OAuth, offering voice account creation unless full control or existing account sign-in is required. Authorization code flow is preferred for security unless a service can't store confidential information, in which case the implicit flow is necessary. GSI requires voice account creation. OAuth linking by itself isn't recommended.\n"],null,["The optimal account linking type for your Action is one that provides the\nsimplest experience for your users and fits the needs of your application or\nbusiness. Choosing your linking type is mostly dependent on the following\nfactors:\n\n- Whether you want to allow account creation via voice\n- Whether you want users to be able to sign in to your service with a non-Google account\n- Whether or not your service can store confidential information (i.e., a client secret)\n\nTo figure out your ideal account linking type, follow these steps:\n\n1. Consider the questions in the [Identify your preferred sign-in type](#identify_your_preferred_sign-in_type) section.\n2. Consult the decision tree to choose your linking type.\n3. Navigate to the section that corresponds to the initial type you chose to further refine how it works.\n\nIdentify your preferred sign-in type\n\nBefore you consult the decision tree, consider the following questions:\n\n- **Do you expect all your users to have a Google account?**\n - If your Action only targets Assistant, then you can expect all your users to have a Google account. If your Action targets platforms beyond Assistant, you cannot expect all your users to have a Google account.\n - If your service already has existing users, it's likely that some don't have a Google account or didn't sign into your service with a Google account.\n- **If you have an OAuth implementation, can it be extended to support Google\n protocol?**\n - To support Google protocol, you need to be able to add the `intent=get` and `intent=create` functionality to your token exchange endpoint. This functionality allows Google to check if the user already exists in your backend and make a request to create a new account on your service, respectively.\n\nFollow the decision tree below to identify the account linking type that's\noptimal for you and your users:\n\nOnce you select a linking type, continue to the corresponding section\nbelow to learn more about how it works and make further decisions about how\naccount linking works in your Action.\n\nOAuth-based Google Sign-in \"Streamlined\" linking\n\nThe Streamlined linking type adds Google Sign-in (GSI) on top of OAuth-based\naccount linking, which provides the benefits of GSI (for example, voice-based\nlinking for Google users) while also enabling account linking for users who\nregistered to your service with a non-Google account. This linking type is\nespecially advantageous for end users because it provides a low-friction flow\nfor Google users with a fallback for non-Google users. For more information\nabout how Streamlined linking works, see the\n[OAuth-based Google Sign-in \"Streamlined\" linking concept guide](/assistant/identity/gsi-oauth-concept-guide).\n\nRefine OAuth-based Google Sign-in \"Streamlined\" linking type\n\nWhen you use the Streamlined linking type in your Action, you specify\nthe answers to the following questions in the Actions console to define how\nit works:\n\n1. **Do you want to enable voice account creation or only allow account\n creation on your website?**\n\n Generally, you should enable account creation via voice so that\n users on a non-screened device can create an account without having to\n transfer to another device. If you do not allow account creation via voice,\n Assistant opens the URL to the web site that you provided for user\n authentication and directs the user to a phone to continue the account\n linking flow.\n\n However, you should not allow account creation via voice if any of the\n following applies:\n 1. *You need full control of the account creation flow.* For example, you may need to show your terms of service to the user during account creation or some other type of notice.\n 2. *You want to ensure that users who already have an account with you\n sign in with that account.* For example, you may want users to continue using their existing accounts if you offer a loyalty program and don't want the user to lose the points accrued on their account.\n2. **Do you want to use the authorization code flow or implicit flow?**\n\n The authorization code flow and implicit flow differ in that the\n authorization code flow requires a second endpoint, the *token exchange*\n endpoint. This endpoint uses *refresh tokens* to generate new, short-lived\n access tokens without prompting the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth-based Google Sign-In \"Streamlined\" linking concept guide](/assistant/identity/gsi-oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs).\n\nAfter considering these decision points, consult the following decision tree:\n\nGoogle Sign-in\n\nWith the Google Sign-in (GSI) linking type, your Action can request access to your user's Google\nprofile during a conversation and use the profile information to check if the\nuser exists in your service's backend. If the user doesn't exist, they can\ncreate a new account in your system using their Google profile information.\n\nFor GSI, you must enable account creation via voice, which lets the user\ncomplete the entire flow over voice. For more information about GSI, see the\n[Google Sign-In concept guide](/assistant/identity/gsi-concept-guide).\n\nOAuth linking\n\nWith the OAuth linking type, the user signs in with the standard OAuth 2.0 flow.\nThe OAuth linking type supports two industry-standard OAuth 2.0 flows:\nthe *implicit* and *authorization* code flows.\n\nGoogle does not recommend the OAuth linking type by itself because it requires transferring\nthe user from voice to screen to complete the sign-in process if the user is on\na non-screened device. You can consider using this flow if you have an existing\nimplementation of an OAuth 2.0 server, and you cannot extend the token exchange\nendpoint to add support for Google's protocols for automatic linking and\naccount creation from an ID token. For more information, see the\n[OAuth linking concept guide](/assistant/identity/oauth-concept-guide).\n\nRefine the flow\n\nWhen you use the OAuth linking type in your Action, you must\nspecify the answer to the following question in the Actions console to define\nhow it works:\n\n1. **Do you want to use the authorization code flow or implicit flow?**\n\n The OAuth linking type supports two industry-standard OAuth 2.0 flows:\n the *implicit* and *authorization* code flows. The authorization code flow\n and implicit flow differ in that the authorization code flow requires a\n second endpoint, the *token exchange* endpoint. This endpoint uses\n *refresh tokens* to generate new, short-lived access tokens without prompting\n the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth linking concept guide](/assistant/identity/oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs)."]]
