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

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

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

คำตอบแบบสั้น ๆ: Logto จัดการ authentication แอปของคุณจัดการ session guest เป็นคนละส่วนกัน

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

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

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

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

แต่ OIDC ไม่ได้ถูกออกแบบมาแบบนั้น เหตุผลคือ:

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

ลองคิดแบบนี้:

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

โหมด guest คือการ track session ไม่ใช่ authentication ดังนั้นจึงไม่ควรอยู่ในระบบ auth ของคุณ

นี่เป็นข่าวดีจริง ๆ เพราะคุณจะแยกส่วนได้ชัดเจน:

• Logto รับผิดชอบเรื่อง identity (สมัคร, ล็อกอิน, token)
• แอปของคุณรับผิดชอบ guest session (ก่อนมี identity)

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

โซลูชั่นสามเฟส#

นี่คือรูปแบบ: Guest → Auth → Merge

เฟส 1: จัดการ guest session โดยไม่ต้อง authentication#

Backend ของคุณสร้างและดูแล guest session โดยที่ Logto ยังไม่เกี่ยวข้อง

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

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

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

เฟส 2: ให้ผู้ใช้ล็อกอินกับ Logto#

เมื่อผู้ใช้คลิก "Sign up" หรือ "Sign in" ให้เรียกการทำงาน OIDC flow ของ Logto ปกติ

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

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

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

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

Backend ของคุณต้องตรวจสอบ token ทั้งสองก่อนจะ merge:

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

หลังจากตรวจสอบผ่านทั้งสองอย่างแล้ว:

3. รวมข้อมูล guest เข้าบัญชีผู้ใช้จริง
4. ยกเลิก guest session

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

วิธีรักษาความปลอดภัย endpoint สำหรับ merge ด้วย token validation#

endpoint สำหรับรวมข้อมูล guest เป็นงานละเอียด ควรพิจารณา:

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

สรุป#

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

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

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