วิธีการใช้งานโหมดแขก (ผู้ใช้แบบไม่ระบุตัวตน) และแปลงเป็นผู้ใช้ Logto

แอปหลายแอปให้ผู้ใช้ทดลองฟีเจอร์ก่อนสมัครใช้งาน เช่น ตะกร้าสินค้า ร่างเอกสาร หรือบันทึกการตั้งค่า ผู้ใช้คาดหวังว่า "โหมดแขก" จะใช้งานได้อย่างราบรื่น

แต่ถ้าคุณใช้ Logto (หรือผู้ให้บริการ OIDC ใด ๆ) เพื่อยืนยันตัวตน คุณอาจสงสัยว่าควรจัดการผู้ใช้แบบไม่ระบุตัวตนอย่างไร?

คำตอบสั้น ๆ: Logto ดูแลการยืนยันตัวตน แอปของคุณดูแลเซสชันแขก แยกกันอย่างชัดเจน

ในบทความนี้ ผมจะแสดงรูปแบบง่าย ๆ แบบสามเฟสในการใช้งานโหมดแขกกับ Logto คุณจะได้เรียนรู้วิธี:

• จัดการเซสชันแขกใน backend ของคุณ
• ให้แขกสมัครสมาชิกผ่าน Logto
• ผสานข้อมูลแขกเข้ากับบัญชีผู้ใช้จริง

ทำไม Logto ถึงไม่มี "anonymous login"#

คุณอาจคาดว่า Logto จะมีฟีเจอร์ "anonymous login" บางอย่าง เช่น เรียก API รับ token โดยไม่ต้องให้ผู้ใช้มีส่วนร่วม

แต่ OIDC ไม่ได้ทำงานแบบนั้น เหตุผลคือ:

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

คิดแบบนี้:

• Authentication = พิสูจน์ตัวตน ("คุณคือใคร?")
• Session tracking = จำการกระทำ ("คุณทำอะไรบ้าง?")

โหมดแขกเกี่ยวกับ session tracking ไม่ใช่ authentication ดังนั้นจึงไม่ควรอยู่บน auth system ของคุณ

นี่คือเรื่องดี! เพราะมันแยกกันอย่างชัดเจน:

• Logto ดูแลเรื่องตัวตน (สมัคร, เข้าสู่ระบบ, โทเคน)
• แอปของคุณดูแลเซสชันแขก (ก่อนจะมีตัวตน)

ให้แต่ละระบบทำหน้าที่ที่มันถูกออกแบบมา

รูปแบบแก้ปัญหา สามเฟส#

แนวทางคือ: Guest → Auth → Merge

เฟส 1: จัดการเซสชันแขกโดยไม่ต้องยืนยันตัวตน#

backend ของคุณจะสร้างและจัดการเซสชันแขก Logto ยังไม่เกี่ยวข้องในขั้นตอนนี้

เมื่อผู้ใช้ทำอะไรที่สำคัญ (เช่น เพิ่มเข้าตะกร้า) backend ของคุณจะ:

1. สร้าง guest ID (เช่น UUID)
2. ส่งคืนเป็น cookie หรือ JWT
3. จัดเก็บการกระทำของผู้ใช้ไว้กับ guest ID นี้

ให้ง่ายเข้าไว้ ตาราง guest_sessions ที่มี guest_id, data, และ created_at ก็เพียงพอแล้ว

เฟส 2: ให้ผู้ใช้เข้าสู่ระบบผ่าน Logto#

เมื่อผู้ใช้คลิก "สมัคร" หรือ "เข้าสู่ระบบ" ให้เรียกขั้นตอนมาตรฐาน OIDC ของ Logto

guest ID ยังคงอยู่ใน cookie/storage ระหว่างกระบวนการนี้ หลังจากยืนยันตัวตนสำเร็จ ฝั่ง frontend ของคุณจะมี:

• access token จาก Logto (ตัวตนผู้ใช้)
• guest ID จากเดิม (ข้อมูลแขก)

เฟส 3: ผสานข้อมูลแขกเข้ากับผู้ใช้ที่ยืนยันตัวตนแล้วอย่างปลอดภัย#

เชื่อมโยงข้อมูลเข้าด้วยกัน โดยเรียก API backend พร้อมทั้งสองอย่าง:

backend ของคุณจะต้องตรวจสอบ โทเคนทั้งสอง ก่อนจะผสานข้อมูล:

1. ตรวจสอบ access token → ดึง user ID ดูวิธี Validate access tokens สำหรับ Logto
2. ตรวจสอบ guest ID → ยืนยันว่าเป็นเซสชันแขกที่ backend คุณสร้างขึ้นเอง ห้ามเชื่อ guest ID ที่ client ส่งโดยไม่ตรวจสอบเด็ดขาด

เฉพาะเมื่อผ่านการตรวจสอบทั้งสองแล้ว:

3. ผสานข้อมูลแขก เข้ากับบัญชีผู้ใช้
4. ยกเลิกเซสชันแขก

ตรรกะในการผสานขึ้นกับธุรกิจของคุณ ตะกร้าสินค้า? รวมรายการ ร่างเอกสาร? เปลี่ยนเจ้าของ คุณเป็นคนตัดสินใจ

วิธีทำให้ endpoint ผสานข้อมูลแขกปลอดภัยด้วยการตรวจสอบโทเคน#

endpoint สำหรับผสานข้อมูลแขกเป็นการดำเนินการที่ละเอียดอ่อน ต้องระวังดังนี้:

• ตรวจสอบ access token เสมอ อย่าอ่าน user ID จาก request body เฉย ๆ ต้องถอดรหัสและตรวจสอบ JWT ดูวิธีสำหรับ Logto ที่นี่
• ตรวจสอบ guest ID เสมอ ตรวจว่ามีอยู่จริงในฐานข้อมูลและยังไม่หมดอายุ ถ้าออกเป็น JWT ให้ตรวจลายเซ็น
• ต้องยืนยันตัวตน end point นี้ควรปฏิเสธคำขอที่ไม่มี access token ที่ถูกต้อง
• กำหนด TTL (เวลาหมดอายุ) ให้เซสชันแขก ลบเซสชันที่ถูกทิ้งหลัง 30 วัน (หรือเวลาที่เหมาะกับแอปของคุณ)

สรุป#

โหมดแขกกับ Logto ใช้รูปแบบง่าย ๆ:

1. Guest (แอปของคุณ) → จัดการเซสชันก่อนที่ผู้ใช้จะสมัคร
2. Auth (Logto) → จัดการสมัครและเข้าสู่ระบบ
3. Merge (แอปของคุณ) → เชื่อมข้อมูลแขกเข้ากับผู้ใช้จริง

รูปแบบนี้ใช้ได้กับผู้ให้บริการ OIDC ทุกเจ้าไม่ใช่แค่ Logto ประเด็นสำคัญคือ: การยืนยันตัวตนกับ session tracking คือเรื่องคนละส่วน ให้แต่ละระบบทำในสิ่งที่มันถูกออกแบบมา