เลือกประเภทการลิงก์บัญชี

ประเภทการลิงก์บัญชีที่เหมาะสมที่สุดสำหรับการดำเนินการของคุณคือประเภทที่ทำให้ผู้ใช้ได้รับประสบการณ์ที่ง่ายที่สุดและตรงกับความต้องการของแอปพลิเคชันหรือธุรกิจของคุณ การเลือกประเภทการลิงก์ส่วนใหญ่จะขึ้นอยู่กับปัจจัยต่อไปนี้

• คุณต้องการอนุญาตให้สร้างบัญชีผ่านเสียงหรือไม่
• คุณต้องการให้ผู้ใช้สามารถลงชื่อเข้าใช้บริการของคุณด้วย บัญชีที่ไม่ใช่ของ Google หรือไม่
• บริการของคุณจะจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์) ได้หรือไม่

โปรดทำตามขั้นตอนต่อไปนี้เพื่อดูประเภทการลิงก์บัญชีที่เหมาะกับคุณ

1. ลองพิจารณาคำถามในส่วนระบุประเภทการลงชื่อเข้าใช้ที่คุณต้องการ
2. ศึกษาแผนผังการตัดสินใจเพื่อเลือกประเภทการลิงก์
3. ไปที่ส่วนที่ตรงกับประเภทเริ่มต้นที่คุณเลือกเพื่อปรับแต่งวิธีการทำงานเพิ่มเติม

ระบุประเภทการลงชื่อเข้าใช้ที่ต้องการ

ก่อนที่จะดูแผนผังการตัดสินใจ ให้พิจารณาคำถามต่อไปนี้

• คุณคาดหวังให้ผู้ใช้ทุกคนมีบัญชี 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

เมื่อคุณใช้ประเภทการลิงก์ที่ได้รับการปรับปรุงให้มีประสิทธิภาพมากขึ้นในการดําเนินการ คุณจะระบุคําตอบสําหรับคําถามต่อไปนี้ในคอนโซลการดําเนินการเพื่อกําหนดวิธีการทำงาน

1. คุณต้องการเปิดใช้การสร้างบัญชีเสียงหรืออนุญาตให้สร้างบัญชีบนเว็บไซต์เท่านั้น

   โดยทั่วไปคุณควรเปิดใช้การสร้างบัญชีผ่านเสียง เพื่อให้ผู้ใช้อุปกรณ์ที่ไม่คัดกรองสามารถสร้างบัญชีได้โดยไม่ต้องโอนไปยังอุปกรณ์อื่น หากคุณไม่อนุญาตให้สร้างบัญชีด้วยเสียง Assistant จะเปิด URL ไปยังเว็บไซต์ที่คุณระบุในการตรวจสอบสิทธิ์ผู้ใช้ และนำผู้ใช้ไปยังโทรศัพท์เพื่อดำเนินการลิงก์บัญชีต่อ

   อย่างไรก็ตาม คุณไม่ควรอนุญาตให้สร้างบัญชีผ่านเสียงในกรณีต่อไปนี้

   1. คุณต้องควบคุมขั้นตอนการสร้างบัญชีได้อย่างสมบูรณ์ ตัวอย่างเช่น คุณอาจต้องแสดงข้อกำหนดในการให้บริการแก่ผู้ใช้ในระหว่างการสร้างบัญชีหรือการแจ้งประเภทอื่น
   2. คุณต้องการให้ผู้ใช้ที่มีบัญชีกับคุณอยู่แล้วลงชื่อเข้าใช้ด้วยบัญชีนั้น เช่น คุณอาจต้องการให้ผู้ใช้ใช้บัญชีที่มีอยู่ต่อไปหากคุณเสนอโปรแกรมสะสมคะแนนและไม่ต้องการให้ผู้ใช้เสียคะแนนสะสมในบัญชี

2. คุณต้องการใช้ขั้นตอนรหัสการให้สิทธิ์หรือขั้นตอนโดยนัย

   ขั้นตอนรหัสการให้สิทธิ์และโฟลว์โดยนัยแตกต่างกันตรงที่ขั้นตอนรหัสการให้สิทธิ์ต้องใช้ปลายทางที่ 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 ในการดำเนินการ คุณต้องระบุคำตอบสำหรับคำถามต่อไปนี้ในคอนโซลการดำเนินการเพื่อกำหนดวิธีการทำงาน

1. คุณต้องการใช้ขั้นตอนรหัสการให้สิทธิ์หรือขั้นตอนโดยนัย

   ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอน implicit และขั้นตอนการให้สิทธิ์ ขั้นตอนรหัสการให้สิทธิ์และขั้นตอนโดยปริยายต่างกันตรงที่ขั้นตอนรหัสการให้สิทธิ์ต้องใช้ปลายทางที่ 2 ซึ่งก็คือปลายทางการแลกเปลี่ยนโทเค็น ปลายทางนี้ใช้โทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึงที่ใช้ได้เป็นระยะเวลาสั้นๆ ใหม่ โดยไม่แจ้งให้ผู้ใช้ลงชื่อเข้าใช้อีกครั้ง

   ในทางกลับกัน หากคุณใช้ขั้นตอนโดยนัย คุณจะส่งคืนโทเค็นเพื่อการเข้าถึงที่ใช้ได้นานให้ Google ซึ่งโดยปกติไม่จำเป็นต้องสร้างขึ้นใหม่ ดูข้อมูลเพิ่มเติมเกี่ยวกับรหัสการให้สิทธิ์และขั้นตอนโดยนัยได้ในคู่มือแนวคิดการลิงก์ OAuth

   Google ขอแนะนำให้ใช้ขั้นตอนรหัสการให้สิทธิ์ในการดําเนินการ เนื่องจากปลอดภัยกว่า แต่ให้ใช้ขั้นตอนโดยนัยแทนหากบริการไม่สามารถจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์) เช่น คุณต้องใช้ขั้นตอนแบบโดยนัยสำหรับไคลเอ็นต์สาธารณะ เช่น แอปพลิเคชันหน้าเว็บเดียว (SPA)