Kontoverknüpfungstyp auswählen
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Der optimale Kontoverknüpfungstyp für deine Aktion ist derjenige, der für die Nutzer besonders einfach zu verwenden ist und den Anforderungen deiner Anwendung oder deines Unternehmens entspricht. Die Wahl des Verknüpfungstyps hängt hauptsächlich von den folgenden Faktoren ab:
- Festlegen, ob Sie die Kontoerstellung per Spracheingabe zulassen möchten
- Festlegen, ob Nutzer sich mit einem Nicht-Google-Konto in Ihrem Dienst anmelden können
- Ob Ihr Dienst vertrauliche Informationen (z.B. Clientschlüssel) speichern kann
So findest du den idealen Kontoverknüpfungstyp:
- Berücksichtigen Sie die Fragen im Abschnitt Bevorzugten Anmeldetyp bestimmen.
- Informationen zur Auswahl des Verknüpfungstyps finden Sie im Entscheidungsbaum.
- Rufen Sie den Bereich auf, der dem ursprünglich ausgewählten Typ entspricht, um die Funktionsweise weiter zu verfeinern.
Bevorzugten Anmeldetyp auswählen
Bevor Sie den Entscheidungsbaum konsultieren, sollten Sie sich die folgenden Fragen stellen:
- Erwarten Sie, dass alle Ihre Nutzer ein Google-Konto haben?
- Wenn deine Aktion nur auf Assistant ausgerichtet ist, kannst du davon ausgehen, dass alle deine Nutzer ein Google-Konto haben. Wenn deine Aktion auf andere Plattformen als Assistant ausgerichtet ist, kannst du nicht erwarten, dass alle deine Nutzer ein Google-Konto haben.
- Wenn Ihr Dienst bereits Nutzer hat, haben diese wahrscheinlich kein Google-Konto oder sie haben sich nicht mit einem Google-Konto bei Ihrem Dienst angemeldet.
- Kann eine OAuth-Implementierung zur Unterstützung des Google-Protokolls erweitert werden?
- Zur Unterstützung des Google-Protokolls müssen Sie die Funktionen
intent=get und intent=create Ihrem Tokenaustausch-Endpunkt hinzufügen können. Mit dieser Funktion kann Google prüfen, ob der Nutzer bereits in Ihrem Back-End vorhanden ist, und eine Anfrage zum Erstellen eines neuen Kontos in Ihrem Dienst senden.
Anhand des folgenden Entscheidungsbaums kannst du den Kontoverknüpfungstyp ermitteln, der für dich und deine Nutzer am besten geeignet ist:
Sobald du einen Verknüpfungstyp ausgewählt hast, fahre mit dem entsprechenden Abschnitt unten fort, um mehr darüber zu erfahren und weitere Entscheidungen zur Kontoverknüpfung in deiner Aktion zu treffen.
„Optimierte“ Verknüpfung mit OAuth-basiertem Google Log-in
Beim Typ „Optimierte Verknüpfung“ wird neben der OAuth-basierten Kontoverknüpfung auch Google Log-in (GSI) hinzugefügt. Das bietet die Vorteile von GSI (z. B. sprachbasierte Verknüpfung für Google-Nutzer) und ermöglicht gleichzeitig die Kontoverknüpfung für Nutzer, die sich mit einem Nicht-Google-Konto bei Ihrem Dienst registriert haben. Dieser Verknüpfungstyp ist besonders für Endnutzer von Vorteil, da er für Google-Nutzer einen reibungslosen Ablauf und für Nicht-Google-Nutzer einen Fallback bietet. Weitere Informationen zur Funktionsweise der optimierten Verknüpfung finden Sie im Konzeptleitfaden „Optimierte“, OAuth-basierte Google Log-in-Verknüpfung.
OAuth-basierten Google Log-in-Verknüpfungstyp „Optimierte“ optimieren
Wenn Sie in Ihrer Aktion den Verknüpfungstyp „Optimierte“ verwenden, geben Sie die Antworten auf die folgenden Fragen in der Actions Console an, um die Funktionsweise zu definieren:
Möchten Sie die Erstellung von Sprachkonten aktivieren oder die Kontoerstellung nur auf Ihrer Website zulassen?
Im Allgemeinen sollten Sie die Kontoerstellung per Spracheingabe aktivieren, damit Nutzer auf einem nicht geprüften Gerät ein Konto erstellen können, ohne es auf ein anderes Gerät übertragen zu müssen. Wenn Sie die Kontoerstellung per Sprachbefehl nicht zulassen, öffnet Assistant die URL zu der Website, die Sie für die Nutzerauthentifizierung angegeben haben, und leitet den Nutzer zu einem Smartphone weiter, um mit der Kontoverknüpfung fortzufahren.
Sie sollten die Kontoerstellung per Spracheingabe jedoch in folgenden Fällen nicht zulassen:
- Sie benötigen die volle Kontrolle über die Kontoerstellung. Beispielsweise kann es sein, dass du dem Nutzer bei der Kontoerstellung oder in einer anderen Form von Benachrichtigungen deine Nutzungsbedingungen vorlegen musst.
- Nutzer, die bereits ein Konto bei Ihnen haben, sollen sich mit diesem Konto anmelden. Sie möchten beispielsweise, dass Nutzer ihre bestehenden Konten weiterverwenden, wenn Sie ein Treuepunkteprogramm anbieten und nicht möchten, dass sie die für ihr Konto gesammelten Punkte verlieren.
Möchten Sie den Vorgang mit Autorisierungscode oder den impliziten Vorgang verwenden?
Der Vorgang mit Autorisierungscode und der implizite Ablauf unterscheiden sich dadurch, dass für den Vorgang mit Autorisierungscode ein zweiter Endpunkt erforderlich ist: der Tokenaustausch-Endpunkt. Dieser Endpunkt verwendet Aktualisierungstokens, um neue, kurzlebige Zugriffstokens zu generieren, ohne den Nutzer zur erneuten Anmeldung aufzufordern.
Wenn Sie umgekehrt den impliziten Ablauf verwenden, geben Sie ein langlebiges Zugriffstoken an Google zurück, das normalerweise nicht neu generiert werden muss. Weitere Informationen zum Autorisierungscode und zu impliziten Abläufen findest du im Leitfaden zur vereinfachten Verknüpfung von OAuth-basiertem Google Log-in.
Google empfiehlt die Verwendung des Vorgangs mit Autorisierungscode in deiner Aktion, da dieser sicherer ist. Verwenden Sie jedoch stattdessen den impliziten Ablauf, wenn Ihr Dienst keine vertraulichen Informationen (z.B. einen Clientschlüssel) speichern kann.
Sie müssen beispielsweise den impliziten Ablauf für öffentliche Clients wie Single-Page-Anwendungen (SPAs) verwenden.
Sehen Sie sich anschließend den folgenden Entscheidungsbaum an:
Google Log-in
Mit dem Verknüpfungstyp „Google Log-in“ (GSI) kann deine Aktion während einer Unterhaltung Zugriff auf das Google-Profil des Nutzers anfordern und anhand der Profilinformationen prüfen, ob der Nutzer im Back-End deines Dienstes vorhanden ist. Wenn der Nutzer nicht vorhanden ist, kann er mit seinen Google-Profilinformationen ein neues Konto in Ihrem System erstellen.
Für GSI müssen Sie die Kontoerstellung per Spracheingabe aktivieren, damit der Nutzer den gesamten Vorgang per Sprachbefehl ausführen kann. Weitere Informationen zu GSI findest du im Konzeptleitfaden Google Log-in.
OAuth-Verknüpfung
Mit dem OAuth-Verknüpfungstyp meldet sich der Nutzer mit dem standardmäßigen OAuth 2.0-Vorgang an.
Der OAuth-Verknüpfungstyp unterstützt zwei branchenübliche OAuth 2.0-Abläufe: den impliziten und den Autorisierungscode.
Google empfiehlt den OAuth-Verknüpfungstyp selbst nicht, da der Nutzer bei Verwendung eines nicht geprüften Geräts von Sprache auf Bildschirm übertragen werden muss, um den Anmeldevorgang abzuschließen. Sie können diesen Ablauf verwenden, wenn Sie bereits eine Implementierung eines OAuth 2.0-Servers haben und den Endpunkt des Tokenaustauschs nicht erweitern können, um Google-Protokolle für die automatische Verknüpfung und Kontoerstellung aus einem ID-Token zu unterstützen. Weitere Informationen finden Sie im Konzeptleitfaden für die OAuth-Verknüpfung.
Ablauf optimieren
Wenn du den OAuth-Verknüpfungstyp in deiner Aktion verwendest, musst du die folgende Frage in der Actions Console beantworten, um die Funktionsweise zu definieren:
Möchten Sie den Vorgang mit Autorisierungscode oder den impliziten Vorgang verwenden?
Der OAuth-Verknüpfungstyp unterstützt zwei branchenübliche OAuth 2.0-Abläufe: den impliziten und den Autorisierungscode. Der Vorgang mit Autorisierungscode und der implizite Ablauf unterscheiden sich dadurch, dass der Vorgang mit Autorisierungscode einen zweiten Endpunkt erfordert, den Endpunkt des Tokenaustauschs. Dieser Endpunkt verwendet Aktualisierungstokens, um neue, kurzlebige Zugriffstokens zu generieren, ohne den Nutzer zur erneuten Anmeldung aufzufordern.
Wenn Sie umgekehrt den impliziten Ablauf verwenden, geben Sie ein langlebiges Zugriffstoken an Google zurück, das normalerweise nicht neu generiert werden muss. Weitere Informationen zum Autorisierungscode und zu impliziten Abläufen finden Sie im Konzeptleitfaden für die OAuth-Verknüpfung.
Google empfiehlt die Verwendung des Vorgangs mit Autorisierungscode in deiner Aktion, da dieser sicherer ist. Verwenden Sie jedoch stattdessen den impliziten Ablauf, wenn Ihr Dienst keine vertraulichen Informationen (z.B. einen Clientschlüssel) speichern kann.
Sie müssen beispielsweise den impliziten Ablauf für öffentliche Clients wie Single-Page-Anwendungen (SPAs) verwenden.
Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.
Zuletzt aktualisiert: 2025-07-25 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
