Elige el tipo de vinculación de cuentas
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
El tipo de vinculación de cuenta óptimo para tu Acción es aquel que proporciona la
experiencia más simple a tus usuarios y que se ajusta a las necesidades de tu aplicación o
empresa. La elección del tipo de vinculación depende en su mayoría de los siguientes factores:
- Si deseas permitir la creación de cuentas por voz
- Si quieres que los usuarios puedan acceder a tu servicio con una Cuenta que no sea de Google
- Indica si tu servicio puede almacenar o no información confidencial (es decir, un secreto del cliente).
Para determinar el tipo ideal de vinculación de cuentas, sigue estos pasos:
- Considera las preguntas de la sección Identifica tu tipo de acceso preferido.
- Consulte el árbol de decisión para elegir su tipo de vinculación.
- Navega a la sección que corresponda al tipo inicial que elegiste para definir mejor cómo funciona.
Identifica tu tipo de acceso preferido
Antes de consultar el árbol de decisiones, ten en cuenta las siguientes preguntas:
- ¿Esperas que todos tus usuarios tengan una Cuenta de Google?
- Si tu Acción solo se orienta a Asistente, es posible que todos los usuarios tengan una Cuenta de Google. Si tu Acción se orienta a otras plataformas además de Asistente, no puedes esperar que todos tus usuarios tengan una Cuenta de Google.
- Si tu servicio ya tiene usuarios existentes, es probable que algunos no tengan una Cuenta de Google o que no hayan accedido al servicio con una.
- Si tienes una implementación de OAuth, ¿se puede extender para admitir el protocolo de Google?
- Para admitir el protocolo de Google, debes poder agregar las funcionalidades
intent=get y intent=create al extremo de intercambio de tokens. Esta funcionalidad permite a Google verificar si el usuario ya existe en tu backend y realizar una solicitud para crear una cuenta nueva en tu servicio, respectivamente.
Sigue el árbol de decisión que se incluye a continuación para identificar el tipo de vinculación de cuentas más adecuado para ti y tus usuarios:
Una vez que selecciones un tipo de vinculación, ve a la sección correspondiente que se encuentra a continuación para obtener más información sobre su funcionamiento y tomar decisiones adicionales sobre el funcionamiento de la vinculación de cuentas en tu Acción.
Vinculación "optimizada" del Acceso con Google basado en OAuth
El tipo de vinculación optimizada agrega el Acceso con Google (GSI) a la vinculación de cuentas basada en OAuth, que proporciona los beneficios de la GSI (por ejemplo, la vinculación por voz para los usuarios de Google) y, al mismo tiempo, permite la vinculación de cuentas para los usuarios que se registraron en tu servicio con una cuenta que no es de Google. Este tipo de vinculación es especialmente beneficioso para los usuarios finales porque les proporciona un flujo de baja fricción con un resguardo para usuarios que no son de Google. Para obtener más información sobre cómo funcionan las vinculaciones optimizadas, consulta la guía del concepto de vinculación "optimizada" del Acceso con Google basado en OAuth.
Definir mejor el tipo de vinculación "optimizado" del Acceso con Google basado en OAuth
Cuando usas el tipo de vinculación optimizado en tu Acción, debes especificar las respuestas a las siguientes preguntas en la Consola de Actions para definir cómo funciona:
¿Quieres habilitar la creación de cuentas de voz o solo
la creación de cuentas en tu sitio web?
En general, debes habilitar la creación de cuentas por voz para que los usuarios de un dispositivo no analizado puedan crear una sin tener que transferirla a otro dispositivo. Si no permites la creación de cuentas por voz, Asistente abrirá la URL del sitio web que proporcionaste para la autenticación de usuarios y lo dirigirá a un teléfono para continuar con el flujo de vinculación de cuentas.
Sin embargo, no debes permitir la creación de cuentas por voz si se cumple alguna de las siguientes condiciones:
- Necesitas control total sobre el flujo de creación de la cuenta. Por ejemplo, es posible que debas mostrar tus Condiciones del Servicio al usuario durante la creación de la cuenta o algún otro tipo de aviso.
- Tu objetivo es asegurarte de que los usuarios que ya tienen una cuenta accedan con ella. Por ejemplo, es posible que desees que los usuarios sigan usando sus cuentas existentes si ofreces un programa de lealtad y no quieres que pierdan los puntos acumulados en su cuenta.
¿Quieres usar el flujo de código de autorización o el implícito?
El flujo de código de autorización y el flujo implícito difieren en que el flujo de código de autorización requiere un segundo extremo, el de intercambio de tokens. Este extremo usa tokens de actualización para generar tokens de acceso nuevos de corta duración sin pedirle al usuario que vuelva a acceder.
Por el contrario, si usas el flujo implícito, debes mostrar a Google un token de acceso de larga duración que, por lo general, no necesita volver a generarse. Para obtener más información sobre el código de autorización y los flujos implícitos, consulta la guía del concepto de vinculación "optimizada" del Acceso con Google basado en OAuth.
Google recomienda usar el flujo de código de autorización en tu Acción porque es más seguro. Sin embargo, usa el flujo implícito si tu servicio no puede almacenar información confidencial (es decir, un secreto del cliente).
Por ejemplo, debes usar el flujo implícito para clientes públicos como aplicaciones de una sola página (SPA).
Después de considerar estos puntos de decisión, consulta el siguiente árbol de decisión:
Acceso con Google
Con el tipo de vinculación de Acceso con Google (GSI), tu Acción puede solicitar acceso al perfil de Google de tu usuario durante una conversación y usar la información del perfil para verificar si el usuario existe en el backend de tu servicio. Si el usuario no existe, puede crear una cuenta nueva en tu sistema con la información de su perfil de Google.
Para la GSI, debes habilitar la creación de cuentas con la voz, lo que le permite al usuario completar todo el flujo por voz. Para obtener más información sobre la GSI, consulta la guía conceptual de Acceso con Google.
vinculación con OAuth
Con el tipo de vinculación de OAuth, el usuario accede con el flujo estándar de OAuth 2.0.
El tipo de vinculación de OAuth es compatible con dos flujos de OAuth 2.0 estándar de la industria: el flujo de código implícito y el de autorización.
Google no recomienda el tipo de vinculación OAuth por sí solo, ya que requiere transferir al usuario de la voz a la pantalla para completar el proceso de acceso si el usuario está usando un dispositivo sin filtro. Puedes considerar usar este flujo si tienes una implementación existente de un servidor de OAuth 2.0 y no puedes extender el extremo de intercambio de tokens para agregar compatibilidad con los protocolos de Google de vinculación automática y creación de cuentas desde un token de ID. Para obtener más información, consulta la guía del concepto de vinculación de OAuth.
Define mejor el flujo
Cuando usas el tipo de vinculación de OAuth en tu Acción, debes especificar la respuesta a la siguiente pregunta en la Consola de Actions para definir cómo funciona:
¿Quieres usar el flujo de código de autorización o el implícito?
El tipo de vinculación de OAuth es compatible con dos flujos de OAuth 2.0 estándar de la industria: el flujo de código implícito y el de autorización. El flujo de código de autorización y el flujo implícito difieren en que el flujo de código de autorización requiere un segundo extremo, el de intercambio de tokens. Este extremo usa
tokens de actualización para generar tokens de acceso nuevos de corta duración sin pedirle
al usuario que vuelva a acceder.
Por el contrario, si usas el flujo implícito, debes mostrar a Google un token de acceso de larga duración que, por lo general, no necesita volver a generarse. Para obtener más información sobre el código de autorización y los flujos implícitos, consulta la guía de conceptos de vinculación de OAuth.
Google recomienda usar el flujo de código de autorización en tu Acción porque es más seguro. Sin embargo, usa el flujo implícito si tu servicio no puede almacenar información confidencial (es decir, un secreto del cliente).
Por ejemplo, debes usar el flujo implícito para clientes públicos como aplicaciones de una sola página (SPA).
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-07-25 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-25 (UTC)"],[[["\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,["# Choose your account linking type\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 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\n### OAuth-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\n#### Refine 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\n### Google 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\n### OAuth 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\n#### Refine 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)."]]
