ไทย

โหมดแขก
ผู้ใช้แบบไม่ระบุตัวตน
แปลงผู้ใช้

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

เรียนรู้วิธีการใช้งานโหมดแขกและแปลงเป็นผู้ใช้ Logto ด้วยรูปแบบสามเฟส: จัดการเซสชันแขก, รับรองความถูกต้องผ่าน OIDC, และผสานข้อมูลแขกเข้ากับบัญชีผู้ใช้อย่างปลอดภัย

Yijun

Developer

1/9/2026

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

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

เริ่มต้นใช้งาน

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

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

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

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

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

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

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

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

คิดแบบนี้:

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

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

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

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

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

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

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

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

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

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

สร้าง guest ID (เช่น UUID)
ส่งคืนเป็น cookie หรือ JWT
จัดเก็บการกระทำของผู้ใช้ไว้กับ 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 ของคุณจะต้องตรวจสอบ โทเคนทั้งสอง ก่อนจะผสานข้อมูล:

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

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

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

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

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

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

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

สรุป

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

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

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

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

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

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

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

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

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

สรุป#

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

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

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

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

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

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

สรุป#

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

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

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

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

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

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

สรุป

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

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

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

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

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

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

สรุป