Scegliere il tipo di collegamento dell'account
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Il tipo di collegamento dell'account ottimale per l'Azione è che offra agli utenti l'esperienza più semplice e che soddisfi le esigenze della tua applicazione o della tua attività. La scelta del tipo di collegamento dipende principalmente dai seguenti fattori:
- Se vuoi consentire la creazione di account tramite comandi vocali
- Se vuoi che gli utenti possano accedere al tuo servizio con un
account non Google
- Indica se il servizio può archiviare informazioni riservate
(ad es. un client secret)
Per determinare il tipo di collegamento dell'account ideale:
- Considera le domande nella sezione
Identificare il tipo di accesso preferito.
- Consulta la struttura decisionale per scegliere il tipo di collegamento.
- Vai alla sezione corrispondente al tipo iniziale che hai scelto per
perfezionare ulteriormente il funzionamento.
Identifica il tipo di accesso che preferisci
Prima di consultare l'albero decisionale, poniti le seguenti domande:
- Prevedi che tutti i tuoi utenti abbiano un Account Google?
- Se l'Azione ha come target solo l'Assistente, tutti gli utenti avranno un Account Google. Se l'Azione ha come target piattaforme diverse dall'Assistente, non puoi aspettarti che tutti i tuoi utenti abbiano un Account Google.
- Se nel servizio sono già presenti utenti, è probabile che alcuni non abbiano un Account Google o non abbiano effettuato l'accesso al servizio con un Account Google.
- Se hai un'implementazione OAuth, può essere estesa per supportare il protocollo
Google?
- Per supportare il protocollo Google, devi poter aggiungere le funzionalità
intent=get
e intent=create all'endpoint di scambio di token. Questa funzionalità consente a Google di verificare se l'utente esiste già nel tuo backend e di effettuare una richiesta per creare un nuovo account sul tuo servizio, rispettivamente.
Segui la struttura decisionale di seguito per identificare il tipo di collegamento dell'account ottimale per te e i tuoi utenti:
Dopo aver selezionato un tipo di collegamento, vai alla sezione corrispondente riportata di seguito per saperne di più su come funziona e prendere ulteriori decisioni in merito al funzionamento del collegamento degli account nell'Azione.
Collegamento "semplificato" di Accedi con Google basato su OAuth
Il tipo di collegamento semplificato aggiunge l'opzione Accedi con Google (GSI) oltre al collegamento dell'account basato su OAuth, che offre i vantaggi di GSI (ad esempio il collegamento vocale per gli utenti Google), abilitando al contempo il collegamento degli account per gli utenti che si sono registrati al tuo servizio con un account non Google. Questo tipo di collegamento è particolarmente vantaggioso per gli utenti finali perché offre un flusso a basso attrito per gli utenti di Google, mentre quello di riserva per gli utenti non Google. Per ulteriori informazioni sul funzionamento del collegamento semplificato, consulta la guida al concetto di collegamento semplificato di Accedi con Google basato su OAuth.
Perfezionare il tipo di collegamento "Semplificato" Accedi con Google basato su OAuth
Quando utilizzi il tipo di collegamento Ottimizzato nell'Azione, devi specificare le risposte alle seguenti domande nella console di Actions per definirne il funzionamento:
Vuoi abilitare la creazione di account vocali o consentire solo la creazione
di account sul tuo sito web?
In genere, è consigliabile abilitare la creazione di account tramite comandi vocali, in modo che gli utenti che utilizzano un dispositivo non incluso in uno schermo possano creare un account senza dover effettuare il trasferimento su un altro dispositivo. Se non consenti la creazione di account tramite comandi vocali, l'assistente apre l'URL al sito web che hai fornito per l'autenticazione utente e indirizza l'utente a un telefono per continuare la procedura di collegamento dell'account.
Tuttavia, non consentire la creazione di account tramite comandi vocali se si verifica una delle seguenti condizioni:
- Devi avere il controllo completo del flusso di creazione degli account. Ad esempio, potresti dover mostrare i tuoi Termini di servizio all'utente durante la creazione dell'account o durante qualche altro tipo di avviso.
- Vuoi assicurarti che gli utenti che hanno già un account sul tuo sito accedano con quell'account. Ad esempio, se offri un programma fedeltà e non vuoi che perdano i punti accumulati sull'account, potresti voler continuare a utilizzare i loro account esistenti.
Vuoi utilizzare il flusso del codice di autorizzazione o il flusso implicito?
Il flusso del codice di autorizzazione e il flusso implicito differiscono per il fatto che il flusso del codice di autorizzazione richiede un secondo endpoint, l'endpoint di scambio di token. Questo endpoint utilizza i token di aggiornamento per generare nuovi token di accesso di breve durata senza chiedere all'utente di eseguire nuovamente l'accesso.
Al contrario, se utilizzi il flusso implicito, invii a Google un token di accesso di lunga durata che di solito non deve essere rigenerato. Per ulteriori informazioni sul codice di autorizzazione e sui flussi impliciti, consulta la guida al concetto di collegamento "Semplificato" di Accedi con Google basato su OAuth.
Google consiglia di utilizzare il flusso del codice di autorizzazione nell'Azione perché è più sicuro. Tuttavia, utilizza il flusso implicito se il servizio non è in grado di archiviare informazioni riservate (ad esempio, un client secret).
Ad esempio, devi utilizzare il flusso implicito per i client pubblici come le applicazioni a pagina singola (APS).
Dopo aver considerato questi punti decisionali, consulta il seguente albero decisionale:
Accedi con Google
Con il tipo di collegamento Accedi con Google (GSI), l'Azione può richiedere l'accesso al profilo Google dell'utente durante una conversazione e utilizzare le informazioni del profilo per verificare se l'utente esiste nel backend del servizio. Se l'utente non esiste, può
creare un nuovo account nel tuo sistema utilizzando le informazioni del suo profilo Google.
Per GSI, devi abilitare la creazione di account tramite voce, che permette all'utente
di completare l'intero flusso con la voce. Per ulteriori informazioni su GSI, consulta la guida concettuale di Accedi con Google.
Collegamento OAuth
Con il tipo di collegamento OAuth, l'utente accede con il flusso OAuth 2.0 standard.
Il tipo di collegamento OAuth supporta due flussi OAuth 2.0 standard di settore:
i flussi di codice implicito e di autorizzazione.
Google sconsiglia il tipo di collegamento OAuth da solo perché richiede il trasferimento dell'utente da voce a schermo per completare la procedura di accesso se l'utente utilizza un dispositivo non filtrato. Puoi prendere in considerazione l'utilizzo di questo flusso se disponi di un'implementazione esistente di un server OAuth 2.0 e non puoi estendere l'endpoint di scambio di token per aggiungere il supporto dei protocolli di Google per il collegamento automatico e la creazione di account da un token ID. Per ulteriori informazioni, consulta la guida al concetto di collegamento OAuth.
Perfeziona il flusso
Quando utilizzi il tipo di collegamento OAuth nell'Azione, devi specificare la risposta alla seguente domanda nella console di Actions per definirne il funzionamento:
Vuoi utilizzare il flusso del codice di autorizzazione o il flusso implicito?
Il tipo di collegamento OAuth supporta due flussi OAuth 2.0 standard di settore:
i flussi di codice implicito e di autorizzazione. Il flusso del codice di autorizzazione
e il flusso implicito differiscono dal fatto che il flusso del codice di autorizzazione richiede un
secondo endpoint, l'endpoint di scambio di token. Questo endpoint utilizza i token di aggiornamento per generare nuovi token di accesso di breve durata senza chiedere all'utente di accedere nuovamente.
Al contrario, se utilizzi il flusso implicito, invii a Google un token di accesso di lunga durata che di solito non deve essere rigenerato. Per ulteriori informazioni sul codice di autorizzazione e sui flussi impliciti, consulta la guida al concetto di collegamento OAuth.
Google consiglia di utilizzare il flusso del codice di autorizzazione nell'Azione perché è più sicuro. Tuttavia, utilizza il flusso implicito se il servizio non è in grado di archiviare informazioni riservate (ad esempio, un client secret).
Ad esempio, devi utilizzare il flusso implicito per i client pubblici come le applicazioni a pagina singola (APS).
Salvo quando diversamente specificato, i contenuti di questa pagina sono concessi in base alla licenza Creative Commons Attribution 4.0, mentre gli esempi di codice sono concessi in base alla licenza Apache 2.0. Per ulteriori dettagli, consulta le norme del sito di Google Developers. Java è un marchio registrato di Oracle e/o delle sue consociate.
Ultimo aggiornamento 2025-07-25 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
