เลือกประเภทการลิงก์บัญชี
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
ประเภทการลิงก์บัญชีที่เหมาะสมที่สุดสำหรับการดำเนินการของคุณคือประเภทที่ทำให้ผู้ใช้ได้รับประสบการณ์ที่ง่ายที่สุดและตรงกับความต้องการของแอปพลิเคชันหรือธุรกิจของคุณ การเลือกประเภทการลิงก์ส่วนใหญ่จะขึ้นอยู่กับปัจจัยต่อไปนี้
- คุณต้องการอนุญาตให้สร้างบัญชีผ่านเสียงหรือไม่
- คุณต้องการให้ผู้ใช้สามารถลงชื่อเข้าใช้บริการของคุณด้วย
บัญชีที่ไม่ใช่ของ Google หรือไม่
- บริการของคุณจะจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์) ได้หรือไม่
โปรดทำตามขั้นตอนต่อไปนี้เพื่อดูประเภทการลิงก์บัญชีที่เหมาะกับคุณ
- ลองพิจารณาคำถามในส่วนระบุประเภทการลงชื่อเข้าใช้ที่คุณต้องการ
- ศึกษาแผนผังการตัดสินใจเพื่อเลือกประเภทการลิงก์
- ไปที่ส่วนที่ตรงกับประเภทเริ่มต้นที่คุณเลือกเพื่อปรับแต่งวิธีการทำงานเพิ่มเติม
ระบุประเภทการลงชื่อเข้าใช้ที่ต้องการ
ก่อนที่จะดูแผนผังการตัดสินใจ ให้พิจารณาคำถามต่อไปนี้
- คุณคาดหวังให้ผู้ใช้ทุกคนมีบัญชี Google ไหม
- หากการดำเนินการของคุณกำหนดเป้าหมายเฉพาะ Assistant เท่านั้น คุณจะเห็นว่าผู้ใช้ทุกคนมีบัญชี Google หากการดำเนินการของคุณกำหนดเป้าหมายไปยังแพลตฟอร์มอื่นนอกเหนือจาก Assistant คุณจะคาดหวังให้ผู้ใช้ทุกคนมีบัญชี Google ไม่ได้
- ถ้าบริการของคุณมีผู้ใช้อยู่แล้ว อาจเป็นไปได้ว่าผู้ใช้บางรายไม่มีบัญชี Google หรือไม่ได้ลงชื่อเข้าใช้บริการด้วยบัญชี Google
- หากใช้ OAuth อยู่ คุณจะขยายให้รองรับโปรโตคอลของ Google ได้ไหม
- คุณต้องเพิ่มฟังก์ชัน
intent=get และ intent=create ไปยังปลายทางของการแลกเปลี่ยนโทเค็นเพื่อรองรับโปรโตคอลของ Google ฟังก์ชันการทำงานนี้ช่วยให้ Google ตรวจสอบได้ว่ามีผู้ใช้อยู่ในแบ็กเอนด์ของคุณแล้วหรือไม่ และส่งคำขอสร้างบัญชีใหม่ในบริการของคุณตามลำดับ
ทำตามแผนผังการตัดสินใจด้านล่างเพื่อระบุประเภทการลิงก์บัญชีที่เหมาะกับคุณและผู้ใช้ที่สุด
เมื่อเลือกประเภทการลิงก์แล้ว ให้ไปยังส่วนที่เกี่ยวข้องด้านล่างเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงานและตัดสินใจเพิ่มเติมเกี่ยวกับวิธีการทำงานของการลิงก์บัญชีในการดำเนินการของคุณ
การลิงก์แบบ "ปรับปรุงให้ดีขึ้น" ด้วย Google Sign-In ที่ใช้ OAuth
ประเภทการลิงก์ที่ปรับปรุงใหม่จะเพิ่ม Google Sign-In (GSI) บนการลิงก์บัญชีแบบ OAuth ซึ่งมีประโยชน์ของ GSI (เช่น การลิงก์ด้วยเสียงสำหรับผู้ใช้ Google) ขณะเดียวกันก็เปิดใช้การลิงก์บัญชีสำหรับผู้ใช้ที่ลงทะเบียนบริการด้วยบัญชีที่ไม่ใช่ Google ด้วย การลิงก์ประเภทนี้มีประโยชน์อย่างยิ่งสำหรับผู้ใช้ปลายทางเพราะช่วยให้ผู้ใช้ Google ใช้งานได้อย่างราบรื่นโดยมีทางเลือกสำรองสำหรับผู้ที่ไม่ได้ใช้ Google ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงานของการลิงก์ที่ปรับปรุงใหม่ได้ในคู่มือแนวคิดการลิงก์ Google Sign-In แบบ "ปรับปรุงประสิทธิภาพ" ที่ใช้ OAuth
ปรับแต่งประเภทการลิงก์ "ปรับปรุงให้ดีขึ้น" ใน Google Sign-In ที่ใช้ OAuth
เมื่อคุณใช้ประเภทการลิงก์ที่ได้รับการปรับปรุงให้มีประสิทธิภาพมากขึ้นในการดําเนินการ คุณจะระบุคําตอบสําหรับคําถามต่อไปนี้ในคอนโซลการดําเนินการเพื่อกําหนดวิธีการทำงาน
คุณต้องการเปิดใช้การสร้างบัญชีเสียงหรืออนุญาตให้สร้างบัญชีบนเว็บไซต์เท่านั้น
โดยทั่วไปคุณควรเปิดใช้การสร้างบัญชีผ่านเสียง เพื่อให้ผู้ใช้อุปกรณ์ที่ไม่คัดกรองสามารถสร้างบัญชีได้โดยไม่ต้องโอนไปยังอุปกรณ์อื่น หากคุณไม่อนุญาตให้สร้างบัญชีด้วยเสียง Assistant จะเปิด URL ไปยังเว็บไซต์ที่คุณระบุในการตรวจสอบสิทธิ์ผู้ใช้ และนำผู้ใช้ไปยังโทรศัพท์เพื่อดำเนินการลิงก์บัญชีต่อ
อย่างไรก็ตาม คุณไม่ควรอนุญาตให้สร้างบัญชีผ่านเสียงในกรณีต่อไปนี้
- คุณต้องควบคุมขั้นตอนการสร้างบัญชีได้อย่างสมบูรณ์ ตัวอย่างเช่น คุณอาจต้องแสดงข้อกำหนดในการให้บริการแก่ผู้ใช้ในระหว่างการสร้างบัญชีหรือการแจ้งประเภทอื่น
- คุณต้องการให้ผู้ใช้ที่มีบัญชีกับคุณอยู่แล้วลงชื่อเข้าใช้ด้วยบัญชีนั้น เช่น คุณอาจต้องการให้ผู้ใช้ใช้บัญชีที่มีอยู่ต่อไปหากคุณเสนอโปรแกรมสะสมคะแนนและไม่ต้องการให้ผู้ใช้เสียคะแนนสะสมในบัญชี
คุณต้องการใช้ขั้นตอนรหัสการให้สิทธิ์หรือขั้นตอนโดยนัย
ขั้นตอนรหัสการให้สิทธิ์และโฟลว์โดยนัยแตกต่างกันตรงที่ขั้นตอนรหัสการให้สิทธิ์ต้องใช้ปลายทางที่ 2 ซึ่งก็คือปลายทางการแลกเปลี่ยนโทเค็น ปลายทางนี้ใช้โทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึงที่มีอายุสั้นใหม่ โดยไม่แจ้งให้ผู้ใช้ลงชื่อเข้าใช้อีกครั้ง
ในทางกลับกัน หากคุณใช้ขั้นตอนโดยนัย คุณจะส่งคืนโทเค็นเพื่อการเข้าถึงที่ใช้ได้นานให้ Google ซึ่งโดยปกติไม่จำเป็นต้องสร้างขึ้นใหม่ ดูข้อมูลเพิ่มเติมเกี่ยวกับรหัสการให้สิทธิ์และโฟลว์โดยนัยได้ที่คู่มือแนวคิดการลิงก์ Google Sign-In แบบ "มีประสิทธิภาพยิ่งขึ้น" ใน OAuth
Google ขอแนะนำให้ใช้ขั้นตอนรหัสการให้สิทธิ์ในการดําเนินการ เนื่องจากปลอดภัยกว่า แต่ให้ใช้ขั้นตอนโดยนัยแทนหากบริการไม่สามารถจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์)
เช่น คุณต้องใช้ขั้นตอนแบบโดยนัยสำหรับไคลเอ็นต์สาธารณะ เช่น แอปพลิเคชันหน้าเว็บเดียว (SPA)
หลังจากพิจารณาประเด็นการตัดสินใจเหล่านี้แล้ว ให้ศึกษาแผนผังการตัดสินใจต่อไปนี้
Google Sign-In
ด้วยประเภทการลิงก์ Google Sign-In (GSI) การดำเนินการของคุณจะสามารถขอสิทธิ์เข้าถึงโปรไฟล์ Google ของผู้ใช้ในระหว่างการสนทนา และใช้ข้อมูลโปรไฟล์ดังกล่าวเพื่อตรวจสอบว่ามีผู้ใช้อยู่ในแบ็กเอนด์ของบริการหรือไม่ หากไม่มีผู้ใช้นี้ เขาสามารถสร้างบัญชีใหม่ในระบบได้โดยใช้ข้อมูลโปรไฟล์ Google
สำหรับ GSI คุณต้องเปิดใช้การสร้างบัญชีผ่านเสียง ซึ่งทำให้ผู้ใช้ดำเนินการขั้นตอนทั้งหมดได้ทางเสียง ดูข้อมูลเพิ่มเติมเกี่ยวกับ GSI ได้ที่คู่มือแนวคิด Google Sign-In
การลิงก์ OAuth
ผู้ใช้จะลงชื่อเข้าใช้ด้วยขั้นตอน OAuth 2.0 มาตรฐานด้วยประเภทการลิงก์ OAuth
ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอน implicit และขั้นตอนการให้สิทธิ์
Google ไม่แนะนำให้ใช้ประเภทการลิงก์ OAuth เนื่องจากต้องมีการโอนผู้ใช้จากเสียงหนึ่งไปยังอีกหน้าจอหนึ่งเพื่อดำเนินการลงชื่อเข้าใช้ให้เสร็จสมบูรณ์ หากผู้ใช้ใช้อุปกรณ์ที่ไม่ได้คัดกรอง คุณจะพิจารณาใช้ขั้นตอนนี้ได้หากคุณใช้เซิร์ฟเวอร์ OAuth 2.0 อยู่แล้ว และคุณไม่สามารถขยายปลายทางการแลกเปลี่ยนโทเค็นเพื่อเพิ่มการรองรับโปรโตคอลของ Google สำหรับการลิงก์อัตโนมัติและการสร้างบัญชีจากโทเค็นรหัส ดูข้อมูลเพิ่มเติมได้ในคู่มือแนวคิดการลิงก์ OAuth
ปรับแต่งขั้นตอน
เมื่อคุณใช้ประเภทการลิงก์ OAuth ในการดำเนินการ คุณต้องระบุคำตอบสำหรับคำถามต่อไปนี้ในคอนโซลการดำเนินการเพื่อกำหนดวิธีการทำงาน
คุณต้องการใช้ขั้นตอนรหัสการให้สิทธิ์หรือขั้นตอนโดยนัย
ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอน implicit และขั้นตอนการให้สิทธิ์ ขั้นตอนรหัสการให้สิทธิ์และขั้นตอนโดยปริยายต่างกันตรงที่ขั้นตอนรหัสการให้สิทธิ์ต้องใช้ปลายทางที่ 2 ซึ่งก็คือปลายทางการแลกเปลี่ยนโทเค็น ปลายทางนี้ใช้โทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึงที่ใช้ได้เป็นระยะเวลาสั้นๆ ใหม่ โดยไม่แจ้งให้ผู้ใช้ลงชื่อเข้าใช้อีกครั้ง
ในทางกลับกัน หากคุณใช้ขั้นตอนโดยนัย คุณจะส่งคืนโทเค็นเพื่อการเข้าถึงที่ใช้ได้นานให้ Google ซึ่งโดยปกติไม่จำเป็นต้องสร้างขึ้นใหม่ ดูข้อมูลเพิ่มเติมเกี่ยวกับรหัสการให้สิทธิ์และขั้นตอนโดยนัยได้ในคู่มือแนวคิดการลิงก์ OAuth
Google ขอแนะนำให้ใช้ขั้นตอนรหัสการให้สิทธิ์ในการดําเนินการ เนื่องจากปลอดภัยกว่า แต่ให้ใช้ขั้นตอนโดยนัยแทนหากบริการไม่สามารถจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์)
เช่น คุณต้องใช้ขั้นตอนแบบโดยนัยสำหรับไคลเอ็นต์สาธารณะ เช่น แอปพลิเคชันหน้าเว็บเดียว (SPA)
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-25 UTC
[null,null,["อัปเดตล่าสุด 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,["The 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\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\nOAuth-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\nRefine 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\nGoogle 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\nOAuth 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\nRefine 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)."]]
