ประเภทการลิงก์บัญชีที่เหมาะสมที่สุดสำหรับการดำเนินการของคุณคือประเภทที่ทำให้ผู้ใช้ได้รับประสบการณ์ที่ง่ายที่สุดและตรงกับความต้องการของแอปพลิเคชันหรือธุรกิจของคุณ การเลือกประเภทการลิงก์ส่วนใหญ่จะขึ้นอยู่กับปัจจัยต่อไปนี้
- คุณต้องการอนุญาตให้สร้างบัญชีผ่านเสียงหรือไม่
- คุณต้องการให้ผู้ใช้สามารถลงชื่อเข้าใช้บริการของคุณด้วย บัญชีที่ไม่ใช่ของ Google หรือไม่
- บริการของคุณจะจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์) ได้หรือไม่
โปรดทำตามขั้นตอนต่อไปนี้เพื่อดูประเภทการลิงก์บัญชีที่เหมาะกับคุณ
- ลองพิจารณาคำถามในส่วนระบุประเภทการลงชื่อเข้าใช้ที่คุณต้องการ
- ศึกษาแผนผังการตัดสินใจเพื่อเลือกประเภทการลิงก์
- ไปที่ส่วนที่ตรงกับประเภทเริ่มต้นที่คุณเลือกเพื่อปรับแต่งวิธีการทำงานเพิ่มเติม
ระบุประเภทการลงชื่อเข้าใช้ที่ต้องการ
ก่อนที่จะดูแผนผังการตัดสินใจ ให้พิจารณาคำถามต่อไปนี้
- คุณคาดหวังให้ผู้ใช้ทุกคนมีบัญชี Google ไหม
- หากการดำเนินการของคุณกำหนดเป้าหมายไปที่ Assistant เท่านั้น คุณสามารถคาดหวังให้ผู้ใช้ทุกคนมีบัญชี Google ได้ หากการดำเนินการของคุณกำหนดเป้าหมายไปยังแพลตฟอร์มอื่นนอกเหนือจาก Assistant คุณจะคาดหวังให้ผู้ใช้ทุกคนมีบัญชี Google ไม่ได้
- ถ้าบริการของคุณมีผู้ใช้อยู่แล้ว อาจเป็นไปได้ว่าผู้ใช้บางรายไม่มีบัญชี Google หรือไม่ได้ลงชื่อเข้าใช้บริการด้วยบัญชี Google
- หากใช้ OAuth อยู่ คุณจะขยายให้รองรับโปรโตคอลของ Google ได้ไหม
- คุณต้องเพิ่มฟังก์ชัน
intent=getและintent=createไปยังปลายทางของการแลกเปลี่ยนโทเค็นเพื่อรองรับโปรโตคอลของ Google ฟังก์ชันการทำงานนี้ช่วยให้ Google ตรวจสอบได้ว่ามีผู้ใช้อยู่ในแบ็กเอนด์ของคุณแล้วหรือไม่ และส่งคำขอสร้างบัญชีใหม่ในบริการของคุณตามลำดับ
- คุณต้องเพิ่มฟังก์ชัน
ทำตามแผนผังการตัดสินใจด้านล่างเพื่อระบุประเภทการลิงก์บัญชีที่เหมาะกับคุณและผู้ใช้ที่สุด
เมื่อเลือกประเภทการลิงก์แล้ว ให้ไปยังส่วนที่เกี่ยวข้องด้านล่างเพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงานและตัดสินใจเพิ่มเติมเกี่ยวกับวิธีการทำงานของการลิงก์บัญชีในการดำเนินการของคุณ
OAuth และ Google Sign-In
ประเภทการลิงก์ OAuth และ Google Sign-In (GSI) จะเพิ่ม GSI ไว้นอกเหนือจากการลิงก์บัญชีแบบ OAuth ซึ่งใช้ประโยชน์จาก GSI (เช่น การลิงก์ด้วยเสียงสำหรับผู้ใช้ Google) ในขณะเดียวกันก็เปิดใช้การลิงก์บัญชีสำหรับผู้ใช้ที่ลงทะเบียนบริการด้วยบัญชีที่ไม่ใช่ Google ด้วย การลิงก์ประเภทนี้มีประโยชน์อย่างยิ่งสำหรับผู้ใช้ปลายทางเพราะช่วยให้ผู้ใช้ Google ใช้งานได้อย่างราบรื่นโดยมีทางเลือกสำรองสำหรับผู้ที่ไม่ได้ใช้ Google ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทำงานของประเภทการลิงก์ OAuth และ GSI ได้ที่คู่มือแนวคิด OAuth และ Google Sign-In
ปรับแต่งประเภทการลิงก์ OAuth และ Google Sign-In
เมื่อคุณใช้ประเภทการลิงก์บัญชี OAuth และ GSI ในการดำเนินการ คุณจะระบุคำตอบของคำถามต่อไปนี้ในคอนโซลการดำเนินการเพื่อกำหนดวิธีการทำงาน
คุณต้องการเปิดใช้การสร้างบัญชีเสียงหรืออนุญาตให้สร้างบัญชีบนเว็บไซต์เท่านั้น
โดยทั่วไปคุณควรเปิดใช้การสร้างบัญชีผ่านเสียง เพื่อให้ผู้ใช้อุปกรณ์ที่ไม่คัดกรองสามารถสร้างบัญชีได้โดยไม่ต้องโอนไปยังอุปกรณ์อื่น หากคุณไม่อนุญาตให้สร้างบัญชีด้วยเสียง Assistant จะเปิด URL ไปยังเว็บไซต์ที่คุณระบุในการตรวจสอบสิทธิ์ผู้ใช้ และนำผู้ใช้ไปยังโทรศัพท์เพื่อดำเนินการลิงก์บัญชีต่อ
อย่างไรก็ตาม คุณไม่ควรอนุญาตให้สร้างบัญชีผ่านเสียงในกรณีต่อไปนี้
- คุณต้องควบคุมขั้นตอนการสร้างบัญชีได้อย่างสมบูรณ์ ตัวอย่างเช่น คุณอาจต้องแสดงข้อกำหนดในการให้บริการแก่ผู้ใช้ในระหว่างการสร้างบัญชีหรือการแจ้งประเภทอื่น
- คุณต้องการให้ผู้ใช้ที่มีบัญชีกับคุณอยู่แล้วลงชื่อเข้าใช้ด้วยบัญชีนั้น เช่น คุณอาจต้องการให้ผู้ใช้ใช้บัญชีที่มีอยู่ต่อไปหากคุณเสนอโปรแกรมสะสมคะแนนและไม่ต้องการให้ผู้ใช้เสียคะแนนสะสมในบัญชี
คุณต้องการใช้ขั้นตอนรหัสการให้สิทธิ์หรือขั้นตอนโดยนัย
ขั้นตอนรหัสการให้สิทธิ์และโฟลว์โดยนัยแตกต่างกันตรงที่ขั้นตอนรหัสการให้สิทธิ์ต้องใช้ปลายทางที่ 2 ซึ่งก็คือปลายทางการแลกเปลี่ยนโทเค็น ปลายทางนี้ใช้โทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึงที่มีอายุสั้นใหม่ โดยไม่แจ้งให้ผู้ใช้ลงชื่อเข้าใช้อีกครั้ง
ในทางกลับกัน หากคุณใช้ขั้นตอนโดยนัย คุณจะส่งคืนโทเค็นเพื่อการเข้าถึงที่ใช้ได้นานให้ Google ซึ่งโดยปกติไม่จำเป็นต้องสร้างขึ้นใหม่ ดูข้อมูลเพิ่มเติมเกี่ยวกับรหัสการให้สิทธิ์และขั้นตอนโดยนัยได้ในคู่มือแนวคิด OAuth และ Google Sign-In
Google ขอแนะนำให้ใช้ขั้นตอนรหัสการให้สิทธิ์ในการดําเนินการ เนื่องจากปลอดภัยกว่า แต่ให้ใช้ขั้นตอนโดยนัยแทนหากบริการไม่สามารถจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์) เช่น คุณต้องใช้ขั้นตอนแบบโดยนัยสำหรับไคลเอ็นต์สาธารณะ เช่น แอปพลิเคชันหน้าเว็บเดียว (SPA)
หลังจากพิจารณาประเด็นการตัดสินใจเหล่านี้แล้ว ให้ศึกษาแผนผังการตัดสินใจต่อไปนี้
Google Sign-In
ด้วยประเภทการลิงก์ GSI การดำเนินการของคุณจะสามารถขอสิทธิ์เข้าถึงโปรไฟล์ Google ของผู้ใช้ในระหว่างการสนทนา และใช้ข้อมูลโปรไฟล์ดังกล่าวเพื่อตรวจสอบว่ามีผู้ใช้อยู่ในแบ็กเอนด์ของบริการหรือไม่ หากไม่มีผู้ใช้นี้ เขาสามารถสร้างบัญชีใหม่ในระบบได้โดยใช้ข้อมูลโปรไฟล์ Google
สำหรับ GSI คุณต้องเปิดใช้การสร้างบัญชีผ่านเสียง ซึ่งทำให้ผู้ใช้ดำเนินการขั้นตอนทั้งหมดได้ทางเสียง ดูข้อมูลเพิ่มเติมเกี่ยวกับ GSI ได้ที่คู่มือแนวคิด Google Sign-In
OAuth
ผู้ใช้จะลงชื่อเข้าใช้ด้วยขั้นตอน OAuth 2 แบบมาตรฐานด้วยประเภทการลิงก์ OAuth ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอน implicit และขั้นตอนการให้สิทธิ์
Google ไม่แนะนำให้ใช้ประเภทการลิงก์ OAuth เนื่องจากต้องมีการโอนผู้ใช้จากเสียงหนึ่งไปยังอีกหน้าจอหนึ่งเพื่อดำเนินการลงชื่อเข้าใช้ให้เสร็จสมบูรณ์ หากผู้ใช้ใช้อุปกรณ์ที่ไม่ได้คัดกรอง คุณจะพิจารณาใช้ขั้นตอนนี้ได้หากมีการใช้งานเซิร์ฟเวอร์ OAuth 2 อยู่แล้ว และคุณไม่สามารถขยายปลายทางการแลกเปลี่ยนโทเค็นเพื่อเพิ่มการรองรับโปรโตคอลของ Google สำหรับการลิงก์อัตโนมัติและการสร้างบัญชีจากโทเค็นรหัส ดูข้อมูลเพิ่มเติมได้ในคู่มือแนวคิด OAuth
ปรับแต่งขั้นตอน
เมื่อคุณใช้ประเภทการลิงก์บัญชี OAuth ในการดำเนินการ คุณต้องระบุคำตอบของคำถามต่อไปนี้ในคอนโซลการดำเนินการเพื่อกำหนดวิธีการทำงาน
คุณต้องการใช้ขั้นตอนรหัสการให้สิทธิ์หรือขั้นตอนโดยนัย
ประเภทการลิงก์ OAuth รองรับขั้นตอน OAuth 2.0 มาตรฐานอุตสาหกรรม 2 ขั้นตอน ได้แก่ ขั้นตอน implicit และขั้นตอนการให้สิทธิ์ ขั้นตอนรหัสการให้สิทธิ์และขั้นตอนโดยปริยายต่างกันตรงที่ขั้นตอนรหัสการให้สิทธิ์ต้องใช้ปลายทางที่ 2 ซึ่งก็คือปลายทางการแลกเปลี่ยนโทเค็น ปลายทางนี้ใช้โทเค็นการรีเฟรชเพื่อสร้างโทเค็นเพื่อการเข้าถึงที่ใช้ได้เป็นระยะเวลาสั้นๆ ใหม่ โดยไม่แจ้งให้ผู้ใช้ลงชื่อเข้าใช้อีกครั้ง
ในทางกลับกัน หากคุณใช้ขั้นตอนโดยนัย คุณจะส่งคืนโทเค็นเพื่อการเข้าถึงที่ใช้ได้นานให้ Google ซึ่งโดยปกติไม่จำเป็นต้องสร้างขึ้นใหม่ ดูข้อมูลเพิ่มเติมเกี่ยวกับรหัสการให้สิทธิ์และขั้นตอนโดยนัยในคู่มือแนวคิด OAuth
Google ขอแนะนำให้ใช้ขั้นตอนรหัสการให้สิทธิ์ในการดําเนินการ เนื่องจากปลอดภัยกว่า แต่ให้ใช้ขั้นตอนโดยนัยแทนหากบริการไม่สามารถจัดเก็บข้อมูลที่เป็นความลับ (เช่น รหัสลับไคลเอ็นต์) เช่น คุณต้องใช้ขั้นตอนแบบโดยนัยสำหรับไคลเอ็นต์สาธารณะ เช่น แอปพลิเคชันหน้าเว็บเดียว (SPA)