การลงชื่อเข้าใช้ด้วย Google ช่วยให้คุณจัดการการตรวจสอบสิทธิ์ผู้ใช้ในเว็บไซต์ได้อย่างรวดเร็วและง่ายดาย ผู้ใช้จะลงชื่อเข้าใช้บัญชี Google ให้คํายินยอม และแชร์ ข้อมูลโปรไฟล์กับแพลตฟอร์มของคุณได้อย่างปลอดภัย
รองรับปุ่มและการปรับแต่งได้หลายแบบเมื่อลงชื่อสมัครใช้และลงชื่อเข้าใช้
การลงชื่อสมัครใช้หมายถึงขั้นตอนในการขอความยินยอมจากเจ้าของบัญชี Google ให้แชร์ข้อมูลโปรไฟล์กับแพลตฟอร์มของคุณ โดยทั่วไปแล้ว ระบบจะสร้างบัญชีใหม่ในเว็บไซต์โดยใช้ข้อมูลที่แชร์นี้ แต่การดําเนินการนี้ไม่ใช่ข้อกําหนด
การลงชื่อเข้าใช้คือการลงชื่อเข้าสู่ระบบผู้ใช้เว็บไซต์ของคุณโดยใช้บัญชี Google ที่ใช้งานอยู่ด้วยปุ่มลงชื่อเข้าใช้ที่ปรับเปลี่ยนในแบบของคุณ หรือการแตะครั้งเดียวและการลงชื่อเข้าใช้อัตโนมัติสําหรับผู้ใช้ที่ลงชื่อเข้าสู่ระบบบัญชี Google ของตนอยู่แล้ว
ดูกรณีศึกษา สําหรับเรื่องราวความสําเร็จของการผสานรวมฟีเจอร์ลงชื่อเข้าใช้ด้วย Google
คุณสามารถใช้ API การให้สิทธิ์ของบริการ Google Identity ซึ่งช่วยให้คุณรับโทเค็นเพื่อการเข้าถึงเพื่อใช้กับ Google API หรือเข้าถึงข้อมูลผู้ใช้ได้
การสาธิตการลงชื่อเข้าใช้ด้วย Google
คลิกปุ่มเพื่อลงชื่อเข้าใช้บัญชี Google
ความเป็นส่วนตัวของผู้ใช้
จะไม่มีการนําข้อมูลจากการลงชื่อเข้าใช้ด้วย Google ไปใช้เพื่อโฆษณาหรือวัตถุประสงค์อื่นๆ ที่ไม่ใช่การรักษาความปลอดภัย
Use Case
สาเหตุบางประการที่ควรลงชื่อเข้าใช้ด้วย Google ในเว็บไซต์มีดังนี้
- เพิ่มปุ่ม "ลงชื่อเข้าใช้ด้วย Google" ที่เห็นได้อย่างชัดเจนและปลอดภัยในหน้าการสร้างบัญชีหรือการตั้งค่าบัญชี
- ป้อนข้อมูลบัญชีใหม่โดยใช้ข้อมูลที่แชร์โดยไม่ได้รับความยินยอมจากโปรไฟล์บัญชี Google
- ผู้ใช้จะลงชื่อเข้าใช้บัญชี Google ได้ 1 ครั้งโดยไม่ต้องป้อนชื่อผู้ใช้หรือรหัสผ่านอีกครั้งในเว็บไซต์อื่นๆ
- เมื่อเข้าชมเพื่อคืนสินค้า ผู้ใช้จะลงชื่อเข้าใช้โดยอัตโนมัติหรือด้วยการคลิกครั้งเดียวทั่วทั้งเว็บไซต์ได้
- ใช้บัญชี Google ที่ยืนยันแล้วเพื่อปกป้องความคิดเห็น การลงคะแนนเสียง หรือแบบฟอร์มจากการละเมิด ขณะที่ยังคงไม่เปิดเผยตัวตน
ฟีเจอร์ที่รองรับ
ฟีเจอร์ต่อไปนี้รองรับโดยฟีเจอร์ลงชื่อเข้าใช้ด้วย Google
- ลงชื่อสมัครใช้หากต้องการสร้างบัญชีใหม่ที่ป้อนข้อมูลอัตโนมัติจากโปรไฟล์บัญชี Google (ไม่บังคับ)
- ลงชื่อเข้าใช้โดยใช้ตัวเลือกบัญชีเพื่อเลือกจากหลายบัญชี
- ลงชื่อเข้าใช้ด้วยการแตะครั้งเดียว หากคุณลงชื่อเข้าใช้บัญชี Google อยู่แล้ว
- ลงชื่อเข้าใช้โดยอัตโนมัติ เมื่อคุณกลับมาเข้าชมอีกครั้งโดยใช้คอมพิวเตอร์ โทรศัพท์ หรือแม้กระทั่งแท็บเบราว์เซอร์หลายแท็บ
- ออกจากระบบเพื่อปิดใช้การลงชื่อเข้าใช้อัตโนมัติในอุปกรณ์ทุกเครื่อง
โปรดทราบว่าสถานะบัญชีอาจส่งผลต่อฟีเจอร์ลงชื่อเข้าใช้ด้วย Google อย่างไร
- การระงับบัญชี Google จะหยุดการลงชื่อเข้าใช้ทุกเว็บไซต์ด้วยการลงชื่อเข้าใช้ด้วย Google
- การลบบัญชี Google หรือบัญชีพาร์ทเนอร์จะส่งผลต่อบัญชีหนึ่ง แต่จะไม่มีผลต่อบัญชีอื่นๆ
เปรียบเทียบกับ OAuth และ OpenId Connect
OAuth และ OpenId Connect เป็นมาตรฐานแบบเปิดซึ่งมีตัวเลือกที่กําหนดค่าได้มากมายเพื่อปรับแต่งลักษณะการทํางานของการตรวจสอบสิทธิ์และขั้นตอนการให้สิทธิ์ โปรดดูรายละเอียดเพิ่มเติมในเอกสารประกอบเกี่ยวกับ OAuth ของ Google
การลงชื่อเข้าใช้ด้วย Google มี SDK เดียวที่ครอบคลุมข้อเสนอที่เกี่ยวข้องมากมาย ซึ่งรวมถึงปุ่มที่ปรับเปลี่ยนในแบบของคุณ การแตะครั้งเดียว การลงชื่อเข้าใช้อัตโนมัติ และการให้สิทธิ์ โดยมุ่งหวังที่จะมอบประสบการณ์การใช้งานแกะกล่องที่ปลอดภัยและสะดวกยิ่งขึ้นสําหรับนักพัฒนาซอฟต์แวร์มากกว่าโปรโตคอล OAuth และ OpenId Connect มาตรฐาน ในขณะเดียวกันก็ให้ประสบการณ์ของผู้ใช้ที่ราบรื่นยิ่งขึ้น
- การลงชื่อเข้าใช้ด้วย Google จะอิงตาม OAuth 2.0 สิทธิ์ที่ผู้ใช้ให้ผ่าน ลงชื่อเข้าใช้ด้วย Google จะเหมือนกันกับสิทธิ์ที่ให้ OAuth และในทางกลับกันด้วย
- OAuth 2.0 เป็นโปรโตคอลมาตรฐานอุตสาหกรรมสําหรับการให้สิทธิ์ด้วย ซึ่งประกอบไปด้วยชุดปลายทางที่ผู้มีส่วนเกี่ยวข้องผสานรวมกับ HTTP
- Google Identity Services Services (GIS) API มีให้บริการในหลายภาษา ซึ่งรวมถึง JavaScript และ HTML ซึ่งให้ทั้งการตรวจสอบสิทธิ์และการให้สิทธิ์
- GIS จะแยกช่วงเวลาการตรวจสอบสิทธิ์จากช่วงเวลาการให้สิทธิ์ ในการตรวจสอบสิทธิ์นี้ การผสานรวมอย่างรวดเร็วสามารถทําได้โดยการผสานรวมองค์ประกอบ UI บางอย่างในเว็บไซต์ เช่น ปุ่มที่ปรับเปลี่ยนในแบบของคุณ, One Tap และการลงชื่อเข้าใช้อัตโนมัติ เป็นต้น องค์ประกอบ UI เหล่านี้ให้ UX การตรวจสอบสิทธิ์ที่สอดคล้องกันในเว็บไซต์ของบุคคลที่สามทั้งหมด ในช่วงการให้สิทธิ์ GIS จะทริกเกอร์ขั้นตอน OAuth เพื่อแสดงผลโทเค็นสําหรับการเข้าถึงข้อมูลในนามของผู้ใช้
- การตรวจสอบสิทธิ์ GIS ทําให้การทํางานร่วมกับฝ่ายที่เชื่อถือง่ายขึ้น และลดภาระของ OAuth และการรักษาความปลอดภัยส่วนใหญ่สําหรับนักพัฒนาซอฟต์แวร์ คุณไม่จําเป็นต้องเลือกจากวิธีการต่างๆ ในการรับโทเค็นเพื่อการเข้าถึงหรือรหัสการให้สิทธิ์ หรือมีความเสี่ยงที่จะเป็นผลของการเลือกแนวทางที่ไม่ถูกต้อง แม้ว่าโปรโตคอล OAuth 2.0 จะแสดงรายละเอียดมากมาย เช่น พารามิเตอร์คําขอ/การตอบกลับของปลายทาง HTTP แต่ GIS จะจัดการรายละเอียดการใช้งานเหล่านี้ให้คุณ นอกจากนี้ GIS ยังมีการรักษาความปลอดภัย สําหรับการป้องกันการปลอมแปลงแบบข้ามเว็บไซต์ (CSRF) โดยค่าเริ่มต้น
- เมื่อใช้ HTML API และเครื่องมือสร้างโค้ด การตรวจสอบสิทธิ์ GIS จะลดแท่งสําหรับการผสานรวมทรัพยากร Dependency อีกต่อไป นักพัฒนาซอฟต์แวร์ JavaScript ไม่จําเป็นต้องสร้างโค้ด ซึ่งจะช่วยลดระดับประสบการณ์ OAuth ที่ต้องใช้และเวลาที่ใช้
- UX ของการให้สิทธิ์ GIS จะอิงตาม OAuth UX โดยสมบูรณ์ อย่างไรก็ตาม ไลบรารี JavaScript ของ GIS จะเพิ่มข้อจํากัดบางอย่างเพื่อให้การผสานรวมของฝ่ายต่างๆ ทําได้ง่ายและปลอดภัยยิ่งขึ้น
- นอกจากนี้ GIS ยังมีฟีเจอร์บางอย่างนอกเหนือจากโปรโตคอล OAuth เช่น ผสานรวม API ข้อมูลเข้าสู่ระบบเครื่องมือจัดการรหัสผ่านและ Federated Credential Manager API (จะเปิดตัวเร็วๆ นี้)
ด้วยบริการข้อมูลประจําตัวของ Google นักพัฒนาซอฟต์แวร์สามารถใช้บริการเฉพาะและผสานรวมเพื่อช่วยให้ผู้ใช้ลงชื่อเข้าใช้เว็บไซต์และแอปของนักพัฒนาซอฟต์แวร์ด้วยข้อมูลเข้าสู่ระบบที่ผู้ใช้เลือก พันธกิจของ GIS คือการสนับสนุนและปรับปรุง UX สําหรับข้อมูลเข้าสู่ระบบหลายประเภท เพื่อลดแถบทางเทคนิคสําหรับการผสานรวมฝ่ายที่เกี่ยวข้อง
ช่วงเวลาการตรวจสอบสิทธิ์และการให้สิทธิ์แยกต่างหาก
หากต้องการขอรับโทเค็นเพื่อการเข้าถึงเพื่อใช้กับ Google API หรือเพื่อเข้าถึงข้อมูลผู้ใช้ คุณต้องเรียก API การให้สิทธิ์บริการ Google Identity ซึ่งเป็น JavaScript API แยกต่างหาก แต่รวมอยู่กับ API การตรวจสอบสิทธิ์
หากเว็บไซต์จําเป็นต้องเรียกใช้ทั้ง API การตรวจสอบสิทธิ์และ API การให้สิทธิ์ คุณจะต้องเรียกใช้ API แยกกันในเวลาที่ต่างกัน ในขณะที่ตรวจสอบสิทธิ์ เว็บไซต์ของคุณจะผสานรวมกับ One Tap, การลงชื่อเข้าใช้อัตโนมัติ และ/หรือปุ่มลงชื่อเข้าใช้ด้วย Google เพื่อให้ผู้ใช้ลงชื่อเข้าใช้หรือลงชื่อสมัครใช้เว็บไซต์ได้ หลังจากนี้ เมื่อจําเป็นต้องเข้าถึงข้อมูลจาก Google คุณต้องเรียกใช้ API การให้สิทธิ์เพื่อขอความยินยอมและรับสิทธิ์เข้าถึงข้อมูล การแยกนี้เป็นไปตามแนวทางปฏิบัติแนะนําเกี่ยวกับการให้สิทธิ์เพิ่มขึ้น ซึ่งคุณขอสิทธิ์ในบริบทต่างๆ
หากต้องการบังคับใช้การแยกนี้ API การตรวจสอบสิทธิ์จะแสดงโทเค็นรหัสที่ใช้ในการลงชื่อเข้าใช้เว็บไซต์ได้เท่านั้น ส่วน API การให้สิทธิ์จะแสดงรหัสหรือโทเค็นเพื่อการเข้าถึงที่ใช้สําหรับการเข้าถึงข้อมูลเท่านั้น แต่ไม่ได้ลงชื่อเข้าใช้
การแยกของผู้ใช้นี้จะทําให้ผู้ใช้ได้รับประสบการณ์การตรวจสอบสิทธิ์ที่สอดคล้องกันในเว็บไซต์ต่างๆ ซึ่งจะทําให้ผู้ใช้ได้รับความไว้วางใจและการใช้งานมากขึ้น และส่งผลให้อัตรา Conversion ของผู้ใช้ในเว็บไซต์ของคุณดียิ่งขึ้น นอกจากนี้ การแยกเวลานี้ทําให้ Google Identity Services ลดระดับประสบการณ์ OAuth ที่ต้องการและเวลาสําหรับนักพัฒนาแอปการตรวจสอบสิทธิ์