选择您的帐号关联类型 (Dialogflow)
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
最适合您的 Action 的账号关联类型应该既能为用户提供最便捷的体验，又能满足您的应用或业务的需求。选择关联类型主要取决于以下因素：
- 是否允许通过语音创建账号
- 您是否希望用户能够使用非 Google 帐号登录您的服务
- 您的服务是否可以存储机密信息（即客户端密钥）
要确定理想的帐号关联类型，请按以下步骤操作：
- 考虑确定您的首选登录类型部分中的问题。
- 请参阅决策树，选择关联类型。
- 转到与您选择的初始类型对应的部分，进一步优化其工作原理。
确定您的首选登录类型
在查阅决策树之前，请考虑以下问题：
- 您是否希望所有用户都拥有 Google 账号？
- 如果您的 Action 仅以 Google 助理为目标平台，那么您的所有用户都应该有 Google 帐号。如果您的 Action 以 Google 助理以外的平台为目标平台，那么所有用户都不能拥有 Google 帐号。
- 如果您的服务已有现有用户，则其中一些用户可能没有 Google 帐号，或者没有使用 Google 帐号登录您的服务。
- 如果您有 OAuth 实现，是否可以扩展它以支持 Google 协议？
- 为了支持 Google 协议，您需要能够向令牌交换端点添加
intent=get 和 intent=create 功能。此功能允许 Google 检查您的后端中是否已存在用户，并分别请求在您的服务上创建新帐号。
请按照以下决策树，确定最适合您和您的用户的帐号关联类型：
选择关联类型后，请继续阅读下文的相应部分，详细了解其运作方式，并进一步决定账号关联在 Action 中的运作方式。
OAuth 和 Google 登录
OAuth 和 Google 登录 (GSI) 关联类型会在基于 OAuth 的帐号关联基础上添加 GSI，这样既能享受 GSI 的优势（例如，面向 Google 用户提供基于语音的关联），还能为使用非 Google 帐号注册服务的用户启用帐号关联。这种关联类型对最终用户特别有益，因为它为 Google 用户提供顺畅的流程，并可供非 Google 用户使用。如需详细了解 OAuth 和 GSI 关联类型的工作原理，请参阅 OAuth 和 Google 登录概念指南。
优化 OAuth 和 Google 登录关联类型
在 Action 中使用 OAuth 和 GSI 账号关联类型时，您需要在 Actions 控制台中指定以下问题的答案，以定义其运作方式：
您是想允许在您的网站上创建语音帐号，还是仅允许创建帐号？
通常，您应允许通过语音创建帐号，以便使用未经过筛查的设备的用户无需转移到其他设备即可创建帐号。如果您不允许通过语音创建帐号，Google 助理会打开您为用户身份验证提供的网站网址，并将用户定向到手机以继续完成帐号关联流程。
但是，如果出现以下任一情况，您不应允许通过语音创建帐号：
- 您需要完全控制帐号创建流程。例如，您可能需要在创建帐号时向用户显示服务条款或接收其他类型的通知。
- 您希望确保已拥有您账号的用户使用该账号登录。例如，如果您提供会员回馈活动，并且不希望用户失去其帐号中累积的积分，您可能希望用户继续使用其现有帐号。
您想使用授权代码流程还是隐式流程？
授权代码流程和隐式流程的不同之处在于授权代码流程需要第二个端点，即令牌交换端点。此端点使用刷新令牌来生成新的短期访问令牌，而不会提示用户再次登录。
相反，如果您使用隐式流程，则会向 Google 返回一个长期有效的访问令牌，该令牌通常不需要重新生成。如需详细了解授权代码和隐式流程，请参阅 OAuth 和 Google 登录概念指南。
Google 建议您在 Action 中使用授权代码流程，因为它更安全。但是，如果您的服务无法存储机密信息（即客户端密钥），请改用隐式流程。例如，您必须对单页应用 (SPA) 等公共客户端使用隐式流程。
在考虑了这些决策点后，请查阅以下决策树：
Google 登录功能
指定 GSI 关联类型后，您的 Action 可以在对话期间请求访问用户的 Google 个人资料，并使用个人资料信息来检查用户是否位于服务后端。如果用户不存在，他们可以使用其 Google 个人资料信息在您的系统中创建新帐号。
对于 GSI，您必须启用通过语音创建帐号的功能，以便用户通过语音完成整个流程。如需详细了解 GSI，请参阅 Google 登录概念指南。
OAuth
如果选择 OAuth 关联类型，用户将通过标准 OAuth 2 流程登录。
OAuth 关联类型支持两种业界标准 OAuth 2.0 流程：隐式和授权代码流程。
Google 不建议单独使用 OAuth 关联类型，因为如果用户使用的是未经筛查的设备，该关联类型需要将用户从语音转移到屏幕来完成登录流程。如果您已有 OAuth 2 服务器实现，并且无法扩展令牌交换端点以添加对 Google 协议的支持，从而自动关联以及基于 ID 令牌创建帐号，则可以考虑使用此流程。如需了解详情，请参阅 OAuth 概念指南。
优化流程
在 Action 中使用 OAuth 账号关联类型时，您必须在 Actions 控制台中指定以下问题的回答来定义其运作方式：
您想使用授权代码流程还是隐式流程？
OAuth 关联类型支持两种业界标准 OAuth 2.0 流程：隐式和授权代码流程。授权代码流程和隐式流程的不同之处在于授权代码流程需要第二个端点，即令牌交换端点。此端点使用刷新令牌生成新的短期访问令牌，而不会提示用户再次登录。
相反，如果您使用隐式流程，则会向 Google 返回一个长期有效的访问令牌，该令牌通常不需要重新生成。如需详细了解授权代码和隐式流程，请参阅 OAuth 概念指南。
Google 建议您在 Action 中使用授权代码流程，因为它更安全。但是，如果您的服务无法存储机密信息（即客户端密钥），请改用隐式流程。例如，您必须对单页应用 (SPA) 等公共客户端使用隐式流程。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-07-26。
[null,null,["最后更新时间 (UTC)：2025-07-26。"],[[["\u003cp\u003eThis guide helps you choose the best account linking type for your Google Action based on factors like user experience and security needs.\u003c/p\u003e\n"],["\u003cp\u003eThree main linking types are discussed: OAuth and Google Sign-In (recommended), Google Sign-In, and OAuth.\u003c/p\u003e\n"],["\u003cp\u003eEach type has different features and considerations, such as whether to allow voice account creation or use authorization code versus implicit flow.\u003c/p\u003e\n"],["\u003cp\u003eDecision trees and further details are provided to refine your chosen linking type for optimal implementation within your Action.\u003c/p\u003e\n"],["\u003cp\u003eOAuth and Google Sign-In offer a combined approach for both Google and non-Google user accounts, providing a smoother experience.\u003c/p\u003e\n"]]],[],null,["# Choose your account linking type (Dialogflow)\n\nThe 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------------------------------------\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 the Assistant, then you can expect all your users to have a Google account. If your Action targets platforms beyond the 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\n### OAuth and Google Sign-In\n\nThe OAuth and Google Sign-In (GSI) linking type adds 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 the OAuth and GSI linking type works, see the\n[OAuth and Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-oauth-concept-guide).\n\n#### Refine the OAuth and Google Sign-In linking type\n\nWhen you use the OAuth and GSI account 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, the\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 and Google Sign-In concept guide](/assistant/df-asdk/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\n### Google Sign-In\n\nWith the 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/df-asdk/identity/gsi-concept-guide).\n\n### OAuth\n\nWith the OAuth linking type, the user signs in with the standard OAuth 2 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 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 concept guide](/assistant/df-asdk/identity/oauth-concept-guide).\n\n#### Refine the flow\n\nWhen you use the OAuth account 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 concept guide](/assistant/df-asdk/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)."]]
