Escolha o tipo de vinculação da sua conta
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O tipo ideal de vinculação de conta para a Ação é aquele que oferece a
experiência mais simples para os usuários e se adapta às necessidades do seu aplicativo ou
empresa. A escolha do tipo de vinculação depende principalmente dos seguintes
fatores:
- Se você quer permitir a criação de contas por voz
- Se você quer que os usuários possam fazer login no seu serviço com uma conta que não seja do Google
- Se o seu serviço pode ou não armazenar informações confidenciais (ou seja, uma chave secreta do cliente)
Para definir o tipo ideal de vinculação de conta, siga estas etapas:
- Considere as perguntas na seção
Identificar seu tipo de login preferido.
- Consulte a árvore de decisão para escolher o tipo de vinculação.
- Navegue até a seção que corresponde ao tipo inicial escolhido para
refinar ainda mais o funcionamento.
Identifique o tipo de login de sua preferência
Antes de consultar a árvore de decisão, considere as seguintes perguntas:
- Você espera que todos os seus usuários tenham uma Conta do Google?
- Se a Ação segmentar apenas o Google Assistente, todos os seus
usuários terão uma Conta do Google. Se a Ação for voltada a plataformas além do
Google Assistente, não espere que todos os usuários tenham uma Conta do Google.
- Se o serviço já tiver usuários, é provável que alguns não tenham uma Conta do Google ou não tenham feito login no serviço com uma Conta do Google.
- Se você tiver uma implementação OAuth, ela poderá ser estendida para oferecer suporte ao protocolo do Google?
- Para oferecer suporte ao protocolo do Google, é preciso adicionar as funcionalidades
intent=get
e intent=create ao endpoint de troca de token. Essa
funcionalidade permite que o Google verifique se o usuário já existe no
back-end e faça uma solicitação para criar uma nova conta no serviço,
respectivamente.
Siga a árvore de decisão abaixo para identificar o tipo de vinculação de conta
ideal para você e seus usuários:
Depois de selecionar um tipo de vinculação, acesse a seção correspondente
abaixo para saber mais sobre como ela funciona e tomar outras decisões sobre como
a vinculação de contas funciona na sua ação.
Vinculação "simplificada" do Login do Google com base em OAuth
O tipo de vinculação simplificada adiciona o Login do Google (GSI) além da vinculação de contas
baseada em OAuth, que oferece os benefícios da GSI (por exemplo, vinculação
por voz para usuários do Google) e permite a vinculação de contas de usuários
registrados no seu serviço com uma conta que não é do Google. Esse tipo de vinculação é
especialmente vantajoso para os usuários finais porque fornece um fluxo de baixo atrito
para usuários do Google com um substituto para usuários que não são do Google. Para mais informações
sobre como a vinculação simplificada funciona, consulte o
Guia explicativo da vinculação simplificada do Login do Google com base em OAuth.
Refinar o tipo de vinculação "Simplificado" do Login do Google com base em OAuth
Ao usar o tipo de vinculação simplificado na sua ação, você especifica
as respostas às seguintes perguntas no Console do Actions para definir como
funciona:
Você quer ativar a criação de contas do Voice ou apenas no seu site?
Geralmente, é necessário ativar a criação de contas por voz para que
os usuários em um dispositivo não filtrado possam criar uma conta sem precisar
transferir para outro dispositivo. Se você não permitir a criação de contas por voz,
o Google Assistente vai abrir o URL do site que você forneceu para autenticação
e direcionar o usuário a um telefone para continuar o fluxo de
vinculação de conta.
No entanto, não permita a criação de contas por voz se alguma das
seguintes condições se aplicar:
- Você precisa de controle total do fluxo de criação da conta. Por exemplo, talvez seja necessário mostrar seus Termos de Serviço ao usuário durante a criação da conta ou algum outro tipo de aviso.
- Você quer garantir que os usuários que já têm uma conta com você
façam login com ela. Por exemplo, você pode querer que os usuários continuem
usando as contas atuais se oferecer um programa de fidelidade e não
quiser que eles percam os pontos acumulados.
Você quer usar o fluxo do código de autorização ou o fluxo implícito?
O fluxo do código de autorização e o fluxo implícito são diferentes porque o
fluxo do código de autorização requer um segundo endpoint, o endpoint
token Exchange. Esse endpoint usa tokens de atualização para gerar novos tokens de acesso de curta duração sem solicitar que o usuário faça login novamente.
Por outro lado, se você usar o fluxo implícito, um token de acesso de longa duração
será retornado ao Google, que geralmente não precisa ser gerado novamente. Para mais
informações sobre o código de autorização e fluxos implícitos, consulte o
guia sobre o conceito de vinculação simplificada do Login do Google baseado em OAuth.
O Google recomenda usar o fluxo de código de autorização na sua Ação
porque ele é mais seguro. No entanto, use o fluxo implícito se o serviço não puder armazenar informações confidenciais (ou seja, uma chave secreta do cliente).
Por exemplo, use o fluxo implícito para clientes públicos, como
aplicativos de página única (SPAs).
Depois de considerar esses pontos de decisão, consulte a seguinte árvore de decisão:
Login do Google+
Com o tipo de vinculação do Login do Google (GSI), sua Ação pode solicitar acesso ao perfil do Google
do usuário durante uma conversa e usar as informações do perfil para verificar se o
usuário existe no back-end do serviço. Se o usuário não existir, ele poderá
criar uma nova conta no seu sistema usando as informações do perfil do Google.
Para a GSI, é necessário ativar a criação de contas por voz, o que permite que o usuário
conclua todo o fluxo por voz. Para saber mais sobre GSI, consulte o
Guia dos conceitos do Login do Google.
Vinculação OAuth
Com o tipo de vinculação do OAuth, o usuário faz login com o fluxo padrão do OAuth 2.0.
O tipo de vinculação do OAuth oferece suporte a dois fluxos de OAuth 2.0 padrão do setor:
fluxos de código implícito e de autorização.
O Google não recomenda o tipo de vinculação OAuth por si só, porque ele exige a transferência
do usuário de voz para tela para concluir o processo de login se ele estiver em
um dispositivo não filtrado. Considere usar esse fluxo se você tiver uma implementação atual de um servidor OAuth 2.0 e não puder estender o endpoint de troca de token para adicionar suporte aos protocolos do Google para vinculação automática e criação de conta a partir de um token de ID. Para mais informações, consulte o
Guia do conceito de vinculação do OAuth.
Refinar o fluxo
Ao usar o tipo de vinculação OAuth na sua Ação, é necessário
especificar a resposta para a seguinte pergunta no Console do Actions para definir
como ele funciona:
Você quer usar o fluxo do código de autorização ou o fluxo implícito?
O tipo de vinculação do OAuth oferece suporte a dois fluxos de OAuth 2.0 padrão do setor:
fluxos de código implícito e de autorização. O fluxo do código de autorização
e o fluxo implícito são diferentes porque o fluxo do código de autorização
exige um segundo endpoint, o endpoint de troca de tokens. Esse endpoint usa tokens de atualização para gerar novos tokens de acesso de curta duração sem solicitar que o usuário faça login novamente.
Por outro lado, se você usar o fluxo implícito, um token de acesso de longa duração
será retornado ao Google, que geralmente não precisa ser gerado novamente. Para mais
informações sobre o código de autorização e os fluxos implícitos, consulte o
guia do conceito de vinculação do OAuth.
O Google recomenda usar o fluxo de código de autorização na sua Ação
porque ele é mais seguro. No entanto, use o fluxo implícito se o serviço não puder armazenar informações confidenciais (ou seja, uma chave secreta do cliente).
Por exemplo, use o fluxo implícito para clientes públicos, como
aplicativos de página única (SPAs).
Exceto em caso de indicação contrária, o conteúdo desta página é licenciado de acordo com a Licença de atribuição 4.0 do Creative Commons, e as amostras de código são licenciadas de acordo com a Licença Apache 2.0. Para mais detalhes, consulte as políticas do site do Google Developers. Java é uma marca registrada da Oracle e/ou afiliadas.
Última atualização 2025-07-25 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
