การเปลี่ยนเส้นทาง vs. การไม่เปลี่ยนเส้นทาง vs. การเข้าสู่ระบบแบบฝัง#
มูลนิธิ OpenID Connect:
ใน OpenID Connect (OIDC) การเปลี่ยนเส้นทางเบราว์เซอร์ไปยังผู้ให้บริการตัวตน (IdP) เป็นส่วนสำคัญของกระบวนการตรวจสอบผู้ใช้ ซึ่งเกิดขึ้นเพราะว่าพรรคที่พึ่งพา (RP) เป็นผู้มอบหมายการตรวจสอบผู้ใช้ไปยัง IdP เมื่อผู้ใช้ระบุข้อมูลประจำตัวให้กับ IdP แล้ว จะมีการส่งคืนโทเคน (เช่น ID และโทเคนการอนุญาต) กลับไปยัง RP ผ่านทางเบราว์เซอร์ ตัวกลไกเปลี่ยนเส้นทางนี้จะรับประกันว่าข้อมูลรับประกันที่ละเอียดอ่อนจะถูกจัดการโดย IdP เท่านั้น ไม่ใช่โดย RP
ตามเกณฑ์ของ OIDC ผู้ใช้ต้องถูกเปลี่ยนเส้นทางไปยังผู้ให้บริการตัวตน (IdP) เพื่อดำเนินการตรวจสอบอย่างปลอดภัย สิ่งนี้ทำให้มั่นใจได้ว่าข้อมูลประจำตัวที่ละเอียดอ่อนจะถูกจัดการโดย IdP ไม่ใช่โดยแอปพลิเคชัน (RP) การเข้าสู่ระบบที่ไม่เปลี่ยนเส้นทางอาจทำให้ข้อมูลประจำตัวของผู้ใช้ถูกเปิดเผย ทำให้เสี่ยงต่อการโจมตี เช่น การลักขโมยข้อมูลประจำตัว ฟิชชิง หรือการโจรกรรมการเข้าใช้การล็อกอิน
เมื่อใช้ Logto ที่อิงกับ OIDC ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังโดเมน Logto ที่ปลอดภัยและได้รับการตรวจสอบเพื่อดำเนินกระบวนการลงชื่อเข้าใช้ให้เสร็จสมบูรณ์ อย่างไรก็ตาม ลูกค้าหลายคนต้องการฝังวิดเจ็ตเข้าสู่ระบบหรือลงทะเบียนตรงไปบนเว็บไซต์ของตน ซึ่งรู้จักกันในชื่อ “การเข้าสู่ระบบแบบฝัง” นี่เป็นการปฏิบัติทั่วไปที่จะเพิ่มอัตราการเปลี่ยนผู้ใช้โดยการผสมผสานแบบฟอร์มลงทะเบียนอีเมลหรือปุ่มเข้าสู่ระบบทางสังคมเข้ากับบริบทของเว็บไซต์
การเข้าสู่ระบบแบบฝังและการเปลี่ยนเส้นทางขัดแย้งกันหรือไม่? — ไม่ขัดแย้ง พวกมันเสริมกันในกระบวนการตรวจสอบผู้ใช้
กรณีศึกษาเกี่ยวกับการเข้าสู่ระบบแบบฝัง#
นี่คือตัวอย่างบางส่วนที่แสดงให้เห็นว่าการเข้าสู่ระบบแบบฝังสามารถนำไปปฏิบัติอย่างปลอดภัยได้อย่างไร:
กรณีที่ 1: ฝังฟิลด์ลงทะเบียนอีเมลบนโฮมเพจ#
เว็บไซต์หลายแห่งแสดงฟิลด์ป้อนอีเมลแบบง่ายและปุ่มลงทะเบียน (เช่น "ลงทะเบียนตอนนี้", "เริ่มต้นใช้งาน", หรือ "ทดลองใช้ฟรี") ที่โดดเด่นบนโฮมเพจ เมื่อส่งอีเมลของพวกเขาแล้ว ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยังหน้าใหม่เพื่อดำเนินการลงทะเบียนต่อไป
ตัวอย่าง:
- Stripe: “เริ่มต้นใช้งานด้วยที่อยู่อีเมล”
กรณีที่ 2: ฝังตัวเลือกลงทะเบียนทั้งหมดข้างเนื้อหา#
สำหรับบล็อกหรือเว็บไซต์เนื้อหา ผู้ใช้ที่ไม่ระบุชื่อสามารถเรียกดูเนื้อหาบางส่วนได้แต่ต้องลงชื่อเข้าใช้เพื่อเข้าถึงเนื้อหาทั้งหมด ฟอร์มลงทะเบียนมักปรากฏข้างหรือต่ำกว่าเนื้อหา
ตัวอย่าง:
- Medium: แสดงการโต้เข้าสู่ระบบเมื่อผู้ใช้ต้องการอ่านบทความทั้งหมด
- X (Twitter): กระตุ้นให้ผู้ใช้ลงทะเบียนเพื่อเข้าถึงโปรแกรมเวลาและคุณลักษณะส่วนบุคคล
ในตัวอย่างเหล่านี้ เฉพาะตัวเลือกลงทะเบียนเริ่มต้น (การป้อนอีเมลหรือปุ่มเข้าสู่ระบบทางสังคม) เท่านั้นที่ถูกฝัง ผู้ใช้จะถูกเปลี่ยนเส้นทางไปยัง IdP เพื่อทำการตรวจสอบอย่างมั่นคง เนื่องจากทั้ง Medium และ X เป็น IdP ของตัวเอง พวกเขาจัดการการตรวจสอบผู้ใช้ผ่านหน้าต่างโมดอลแทนที่จะเปลี่ยนเส้นทาง ทำให้เกิดประสบการณ์ผู้ใช้ที่คล้ายคลึงในทั้งสองกรณี
วิธีฝังตัวเลือกการลงทะเบียนในเว็บไซต์ของคุณ?#
ใช้ พารามิเตอร์การตรวจสอบ ของ Logto direct_sign_in, first_screen, และ login_hint เพื่อฝังการลงทะเบียนหรือลงชื่อเข้างานแบบฝัง ข้างล่างนี้คือสองแนวปฏิบัติที่ดีที่สุด:
การเข้าสู่ระบบตรง#
แสดงปุ่มเข้าสู่ระบบทางสังคม (เช่น Google, Facebook, Apple) หรือปุ่มเข้าสู่ระบบทางบริษัท (เช่น Google Workspace, Azure AD, Okta) ในเว็บไซต์ของคุณและเปลี่ยนเส้นทางผู้ใช้ตรงไปยังผู้ให้บริการที่เกี่ยวข้อง รูปแบบที่รองรับในปัจจุบันรวมถึง:
social:<idp-name> (ใช้ตัวเชื่อมทางสังคมกับ IdP ชื่อที่ระบุ, เช่น social:google)sso:<connector-id> (ใช้ตัวเชื่อม SSO ขององค์กรที่ระบุ, เช่น sso:123456)
เรียนรู้เพิ่มเติมใน ส่วนการเข้าสู่ระบบตรงของ Logto Docs
หน้าจอแรก#
นอกจากที่จะสามารถข้ามไปยังผู้ให้บริการตัวตนของบุคคลที่สาม (เช่น Google หรือ Facebook เข้าสู่ระบบ), วิธีการตรวจสอบอื่น ๆ ต้องมีการเปลี่ยนเส้นทางไปยังหน้าจอเข้าสู่ระบบของ Logto เพื่อดำเนินการต่อ โดยสรุปกระบวนการตรวจสอบทั้งหมดจำเป็นต้องเปลี่ยนเส้นทาง — ไม่ว่าจะไปยัง IdP ของบุคคลที่สามหรือไปยัง Logto ในฐานะ IdP แรกของคุณ
พารามิเตอร์ first_screen นี้อนุญาตให้คุณกำหนดค่าแรกที่ผู้ใช้จะเห็นเมื่อเริ่มกระบวนการตรวจสอบ ค่าของพารามิเตอร์นี้สามารถเป็น:
sign_in: อนุญาตให้ผู้ใช้เข้าถึงหน้าเข้าสู่ระบบได้โดยตรงregister: อนุญาตให้ผู้ใช้เข้าถึงหน้าลงทะเบียนได้โดยตรงsingle_sign_on: อนุญาตให้ผู้ใช้เข้าถึงหน้า single sign-on (SSO) ได้โดยตรงidentifier:sign_in: อนุญาตให้ผู้ใช้เข้าถึงหน้าแสดงเฉพาะวิธีการลงชื่อเข้าใช้ที่ใช้ตัวระบุโดยเฉพาะได้โดยตรงidentifier:register: อนุญาตให้ผู้ใช้เข้าถึงหน้าแสดงเฉพาะวิธีการลงทะเบียนที่ใช้ตัวระบุโดยเฉพาะได้โดยตรงreset_password: อนุญาตให้ผู้ใช้เข้าถึงหน้าหน้ารีเซ็ตรหัสผ่านได้โดยตรง
เรียนรู้เพิ่มเติมใน ส่วนหน้าจอแรกของ Logto Docs
คำแนะนำการเข้าสู่ระบบ#
ดังที่กล่าวไว้ก่อนหน้านี้ คุณไม่สามารถรวบรวมรหัสผ่านของผู้ใช้หรือรหัสยืนยัน email/SMS ได้โดยตรงในเว็บไซต์ของคุณ เหล่านี้จะต้องถูกจัดการและตรวจสอบโดย IdP
อย่างไรก็ตาม คุณสามารถรวบรวมที่อยู่อีเมลหรือหมายเลขโทรศัพท์ของผู้ใช้เป็นตัวระบุและส่งไปเมื่อเปลี่ยนเส้นทางไปยังหน้าจอแรกที่เหมาะสม (เช่น register หรือ identifier:register) ในการทำเช่นนี้ ให้ใช้งานพารามิเตอร์ login_hint เพื่อส่งตัวระบุจากเว็บไซต์ของคุณไปยังหน้าจอเข้าสู่ระบบของ Logto URL ที่อาจดูเหมือนนี้: https://auth.example.com/identifier:[email protected]
สำหรับรายละเอียดเพิ่มเติม โปรดดู คำขอการตรวจสอบของข้อบังคับ OIDC
บทสรุป#
โดยใช้ประโยชน์จากพารามิเตอร์ direct_sign_in, first_screen, และ login_hint ของ Logto คุณสามารถฝังฟอร์มลงทะเบียนและเข้าสู่ระบบในเว็บไซต์ของคุณได้อย่างง่ายดาย เพื่อความปลอดภัย เป็นมิตรกับผู้ใช้ขณะเดียวกันยังช่วยเพิ่มอัตราการเปลี่ยนของผู้ใช้
