Memilih jenis penautan akun
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Jenis penautan akun yang optimal untuk Action Anda adalah yang memberikan
pengalaman paling sederhana bagi pengguna dan sesuai dengan kebutuhan aplikasi atau
bisnis Anda. Memilih jenis penautan sebagian besar bergantung pada faktor-faktor berikut:
- Apakah Anda ingin mengizinkan pembuatan akun melalui suara atau tidak
- Apakah Anda ingin pengguna dapat login ke layanan Anda dengan
akun non-Google atau tidak
- Apakah layanan Anda dapat menyimpan informasi rahasia atau tidak (misalnya, rahasia klien)
Untuk mengetahui jenis penautan akun ideal Anda, ikuti langkah-langkah berikut:
- Pertimbangkan pertanyaan di bagian Mengidentifikasi jenis login pilihan Anda.
- Lihat pohon keputusan untuk memilih jenis penautan Anda.
- Buka bagian yang sesuai dengan jenis awal yang Anda pilih untuk
mempertajam cara kerjanya.
Mengidentifikasi jenis login pilihan Anda
Sebelum Anda melihat pohon keputusan, pertimbangkan pertanyaan-pertanyaan berikut:
- Apakah Anda berharap semua pengguna memiliki Akun Google?
- Jika Action hanya menargetkan Asisten, semua pengguna
akan memiliki Akun Google. Jika Action Anda menargetkan platform di luar
Asisten, Anda tidak dapat mengharapkan semua pengguna memiliki Akun Google.
- Jika layanan Anda sudah memiliki pengguna, mungkin ada beberapa pengguna yang tidak memiliki Akun Google atau tidak login ke layanan Anda dengan Akun Google.
- Jika Anda memiliki implementasi OAuth, dapatkah diperpanjang untuk mendukung protokol
Google?
- Untuk mendukung protokol Google, Anda harus dapat menambahkan fungsi
intent=get dan intent=create ke endpoint pertukaran token Anda. Fungsi
ini memungkinkan Google memeriksa apakah pengguna sudah ada di
backend Anda dan mengajukan permintaan untuk membuat akun baru di layanan Anda.
Ikuti pohon keputusan di bawah untuk mengidentifikasi jenis penautan akun yang optimal bagi Anda dan pengguna:
Setelah memilih jenis penautan, lanjutkan ke bagian yang sesuai di bawah ini untuk mempelajari lebih lanjut cara kerjanya dan membuat keputusan lebih lanjut tentang cara kerja penautan akun dalam Action Anda.
Penautan "Sederhana" Login dengan Google berbasis OAuth
Jenis penautan yang disederhanakan ini menambahkan Login dengan Google (GSI) selain penautan akun berbasis OAuth, yang memberikan manfaat GSI (misalnya, penautan berbasis suara untuk pengguna Google) sekaligus memungkinkan penautan akun bagi pengguna yang mendaftar ke layanan Anda dengan akun non-Google. Jenis penautan ini
sangat bermanfaat bagi pengguna akhir karena memberikan alur yang lancar
bagi pengguna Google dengan penggantian bagi pengguna non-Google. Untuk informasi selengkapnya
tentang cara kerja Penautan yang disederhanakan, lihat
panduan konsep penautan "Disederhanakan" untuk Login dengan Google berbasis OAuth.
Menyempurnakan jenis penautan "Sederhanakan" Login dengan Google berbasis OAuth
Saat menggunakan jenis penautan Sederhana di Action, Anda menentukan
jawaban atas pertanyaan berikut di Konsol Actions untuk menentukan
cara kerjanya:
Apakah Anda ingin mengaktifkan pembuatan akun suara atau hanya mengizinkan pembuatan
akun di situs Anda?
Biasanya, Anda harus mengaktifkan pembuatan akun melalui suara sehingga
pengguna pada perangkat yang tidak disaring dapat membuat akun tanpa harus
mentransfer ke perangkat lain. Jika Anda tidak mengizinkan pembuatan akun melalui suara,
Asisten akan membuka URL ke situs yang Anda berikan untuk autentikasi
pengguna dan mengarahkan pengguna ke ponsel untuk melanjutkan alur
penautan akun.
Namun, Anda tidak boleh mengizinkan pembuatan akun melalui suara jika salah satu dari hal berikut berlaku:
- Anda memerlukan kontrol penuh atas alur pembuatan akun. Misalnya, Anda mungkin perlu menampilkan persyaratan layanan kepada pengguna selama
pembuatan akun atau jenis pemberitahuan lainnya.
- Anda ingin memastikan bahwa pengguna yang sudah memiliki akun Anda sudah login dengan akun tersebut. Misalnya, Anda mungkin ingin pengguna terus
menggunakan akun mereka yang ada jika Anda menawarkan program loyalitas dan tidak ingin
pengguna kehilangan poin yang diperoleh di akun mereka.
Apakah Anda ingin menggunakan alur kode otorisasi atau alur implisit?
Alur kode otorisasi dan alur implisit berbeda karena alur kode otorisasi memerlukan endpoint kedua, yaitu endpoint pertukaran token. Endpoint ini menggunakan token refresh untuk membuat token akses baru yang berumur pendek
tanpa meminta pengguna untuk login lagi.
Sebaliknya, jika menggunakan alur implisit, Anda akan menampilkan token akses yang berumur panjang ke Google yang biasanya tidak perlu dibuat ulang. Untuk informasi
selengkapnya tentang kode otorisasi dan alur implisit, lihat
Panduan konsep penautan "Disederhanakan" Login dengan Google berbasis OAuth.
Google merekomendasikan untuk menggunakan alur kode otorisasi dalam Action Anda
karena lebih aman. Namun, gunakan alur implisit jika
layanan Anda tidak dapat menyimpan informasi rahasia (yaitu, rahasia klien).
Misalnya, Anda harus menggunakan alur implisit untuk klien publik seperti
aplikasi web satu halaman (SPA).
Setelah mempertimbangkan poin-poin keputusan ini, lihat pohon keputusan berikut:
Login dengan Google
Dengan jenis penautan Login dengan Google (GSI), Action Anda dapat meminta akses ke profil Google
pengguna selama percakapan dan menggunakan informasi profil untuk memeriksa
apakah pengguna tersebut ada di backend layanan Anda. Jika pengguna tidak ada, mereka dapat
membuat akun baru di sistem Anda menggunakan informasi profil Google-nya.
Untuk GSI, Anda harus mengaktifkan pembuatan akun melalui suara, yang memungkinkan pengguna
menyelesaikan seluruh alur melalui suara. Untuk mengetahui informasi selengkapnya tentang GSI, lihat
Panduan konsep Login dengan Google.
Penautan OAuth
Dengan jenis penautan OAuth, pengguna login dengan alur OAuth 2.0 standar.
Jenis penautan OAuth mendukung dua alur OAuth 2.0 standar industri: alur kode implisit dan otorisasi.
Google tidak merekomendasikan jenis penautan OAuth itu sendiri karena mengharuskan transfer
pengguna dari suara ke layar untuk menyelesaikan proses login jika pengguna menggunakan
perangkat yang tidak disaring. Anda dapat mempertimbangkan untuk menggunakan alur ini jika Anda sudah memiliki penerapan server OAuth 2.0, dan Anda tidak dapat memperluas endpoint pertukaran token guna menambahkan dukungan bagi protokol Google untuk penautan otomatis dan pembuatan akun dari token ID. Untuk informasi selengkapnya, lihat
Panduan konsep penautan OAuth.
Menyempurnakan alur
Saat menggunakan jenis penautan OAuth di Action, Anda harus
menentukan jawaban atas pertanyaan berikut di konsol Actions untuk menentukan
cara kerjanya:
Apakah Anda ingin menggunakan alur kode otorisasi atau alur implisit?
Jenis penautan OAuth mendukung dua alur OAuth 2.0 standar industri: alur kode implisit dan otorisasi. Terdapat perbedaan alur kode otorisasi dan alur implisit karena alur kode otorisasi memerlukan endpoint kedua, yaitu endpoint pertukaran token. Endpoint ini menggunakan token refresh untuk membuat token akses baru yang berumur pendek tanpa meminta pengguna untuk login lagi.
Sebaliknya, jika menggunakan alur implisit, Anda akan menampilkan token akses yang berumur panjang ke Google yang biasanya tidak perlu dibuat ulang. Untuk informasi
selengkapnya tentang kode otorisasi dan alur implisit, lihat
Panduan konsep penautan OAuth.
Google merekomendasikan untuk menggunakan alur kode otorisasi dalam Action Anda
karena lebih aman. Namun, gunakan alur implisit jika
layanan Anda tidak dapat menyimpan informasi rahasia (yaitu, rahasia klien).
Misalnya, Anda harus menggunakan alur implisit untuk klien publik seperti
aplikasi web satu halaman (SPA).
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-25 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)."]]
