ข้ามไปยังเนื้อหาหลัก

การสมัครสมาชิกและการลงชื่อเข้าใช้

การสมัครสมาชิกและการลงชื่อเข้าใช้เป็นกระบวนการโต้ตอบหลักสำหรับผู้ใช้ปลายทางในการยืนยันตัวตน (Authentication) และอนุญาต (Authorization) การเข้าถึงแอปพลิเคชันไคลเอนต์ ในฐานะแพลตฟอร์ม CIAM แบบศูนย์กลางที่ใช้ OIDC Logto มอบประสบการณ์การลงชื่อเข้าใช้แบบสากลให้กับผู้ใช้ข้ามแอปพลิเคชันและแพลตฟอร์มต่าง ๆ

โฟลว์ของผู้ใช้​

ในโฟลว์การยืนยันตัวตน (Authentication) แบบ OIDC ทั่วไป ผู้ใช้เริ่มต้นด้วยการเปิดแอปไคลเอนต์ แอปไคลเอนต์จะส่ง คำขอการอนุญาต (authorization request) ไปยัง Logto OIDC provider หากผู้ใช้ยังไม่มีเซสชันที่ใช้งานอยู่ Logto จะนำผู้ใช้ไปยังหน้าประสบการณ์การลงชื่อเข้าใช้ที่โฮสต์โดย Logto ผู้ใช้โต้ตอบกับหน้า Logto experience และได้รับการยืนยันตัวตนโดยกรอกข้อมูลรับรองที่จำเป็น เมื่อผู้ใช้ได้รับการยืนยันตัวตนสำเร็จ Logto จะเปลี่ยนเส้นทางผู้ใช้กลับไปยังแอปไคลเอนต์พร้อม authorization code จากนั้นแอปไคลเอนต์จะส่ง คำขอโทเค็น (token request) ไปยัง Logto OIDC provider พร้อม authorization code เพื่อรับโทเค็น

การโต้ตอบของผู้ใช้​

เซสชันการโต้ตอบ (interaction session) จะถูกสร้างขึ้นสำหรับแต่ละการโต้ตอบของผู้ใช้เมื่อแอปไคลเอนต์เริ่มต้นคำขอการอนุญาต เซสชันนี้จะรวมสถานะการโต้ตอบของผู้ใช้ข้ามแอปไคลเอนต์หลายตัว ทำให้ Logto สามารถมอบประสบการณ์การลงชื่อเข้าใช้ที่ต่อเนื่อง เมื่อผู้ใช้สลับระหว่างแอปไคลเอนต์ เซสชันการโต้ตอบจะยังคงเหมือนเดิม รักษาสถานะการยืนยันตัวตนของผู้ใช้และลดความจำเป็นในการลงชื่อเข้าใช้ซ้ำข้ามแพลตฟอร์ม เมื่อ เซสชันการโต้ตอบ ถูกสร้างขึ้นแล้ว ผู้ใช้จะถูกแจ้งให้ลงชื่อเข้าใช้ Logto

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

เพื่อสนับสนุนและควบคุมเส้นทางของผู้ใช้นี้ Logto มีชุด Experience API ที่อิงตามเซสชัน API เหล่านี้ช่วยให้ experience app จัดการวิธีการระบุตัวตนและการตรวจสอบผู้ใช้ได้หลากหลาย โดยอัปเดตและเข้าถึงสถานะเซสชันการโต้ตอบแบบเรียลไทม์

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

บันทึก:

หน้า Experience ถูกออกแบบให้เข้าถึงได้เฉพาะผ่านโฟลว์การยืนยันตัวตน (Authentication flow) เท่านั้น เพื่อป้องกันไม่ให้เครื่องมือค้นหาทำดัชนีหน้าเหล่านี้และหลีกเลี่ยงการเข้าถึงโดยตรง Logto จะเพิ่ม <meta name="robots" content="noindex, nofollow" /> ให้กับหน้า HTML ของ experience โดยอัตโนมัติ

การปรับแต่งประสบการณ์การลงชื่อเข้าใช้​

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

ศึกษาต่อเกี่ยวกับ การตั้งค่าประสบการณ์การลงชื่อเข้าใช้ และ การปรับแต่ง ใน Logto

วิธีการลงชื่อเข้าใช้ที่พบบ่อย​

ขึ้นอยู่กับความต้องการของผลิตภัณฑ์ คุณสามารถผสมผสานวิธีการลงชื่อเข้าใช้หลายแบบในประสบการณ์ที่โฮสต์โดย Logto เดียวกันได้:

คำถามที่พบบ่อย​

วิธีหรือแบรนด์ประสบการณ์การลงชื่อเข้าใช้เฉพาะแอป​

สำหรับแอปพลิเคชันหรือองค์กรที่ต้องการ UI การลงชื่อเข้าใช้ ที่แตกต่าง Logto รองรับ การตั้งค่าแบรนด์เฉพาะแอป และ การตั้งค่าแบรนด์เฉพาะองค์กร

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

จำกัดโดเมนอีเมล / ที่อยู่ IP / ภูมิภาค​

สำหรับการควบคุมการเข้าถึงตามคุณลักษณะ (attribute-based access control) เช่น การจำกัดการลงชื่อเข้าใช้ตามโดเมนอีเมล ที่อยู่ IP หรือภูมิภาค คุณสามารถใช้ฟีเจอร์ Custom token claims ใน Logto เพื่อปฏิเสธหรืออนุญาตคำขอการอนุญาตตามคุณลักษณะของผู้ใช้

Headless API สำหรับการลงชื่อเข้าใช้และสมัครสมาชิก​

ปัจจุบัน Logto ยังไม่มี Headless API สำหรับการลงชื่อเข้าใช้และสมัครสมาชิก อย่างไรก็ตาม คุณสามารถนำ UI ลงชื่อเข้าใช้ของคุณเองมาใช้ได้โดยใช้ Bring your own UI เพื่อปรับแต่งประสบการณ์การลงชื่อเข้าใช้และสมัครสมาชิก

เหตุผลที่คุณควรเลิกใช้ Resource Owner Password Credentials (ROPC) grant type

ทำไมคุณควรใช้ authorization code flow แทน implicit flow?

เปรียบเทียบการยืนยันตัวตนแบบใช้โทเค็นกับแบบใช้เซสชัน