วิธีเพิ่มระบบล็อกอินให้แอปของคุณ: รหัสผ่าน ลิงก์เมจิก Google และบทบาท

การเพิ่มการล็อกอินให้แอป ให้เลือกวิธี ได้แก่ อีเมลและรหัสผ่าน magic link (ลิงก์เข้าสู่ระบบแบบใช้ครั้งเดียวที่ส่งทางอีเมล) หรือ "เข้าสู่ระบบด้วย Google" แล้วใช้ไลบรารียืนยันตัวตนที่ผ่านการพิสูจน์แล้วหรือผู้ให้บริการแบบโฮสต์ แทนการเขียนเองตั้งแต่ต้น จากนั้นกำหนดว่าผู้ใช้แต่ละประเภททำอะไรได้ (บทบาท) และบังคับใช้ที่เซิร์ฟเวอร์สำหรับทุกหน้าและทุกคำขอ API เซสชันควรใช้คุกกี้ที่ปลอดภัย มีวันหมดอายุ และสิ้นสุดอย่างถูกต้องเมื่อออกจากระบบ

คู่มือนี้พาดูทีละตัวเลือกและรายละเอียดที่แยกการล็อกอินที่ใช้งานได้ออกจากการล็อกอินที่ปลอดภัย แนวคิดเบื้องหลังอยู่ที่ การยืนยันตัวตนคืออะไร

ตัดสินใจก่อน: คุณต้องมีการล็อกอินหรือไม่?

การล็อกอินเพิ่มความยุ่งยากและความรับผิดชอบ คุณต้องใช้เมื่อ:

• ผู้ใช้มีข้อมูลส่วนตัว (การจอง เอกสาร ใบแจ้งหนี้)
• ผู้ใช้เปลี่ยนแปลงสิ่งที่คนอื่นจะเห็น
• คุณเก็บเงินสำหรับการเข้าถึง
• คนต่างกลุ่มต้องการสิทธิ์ต่างกัน (เจ้าของ พนักงาน ลูกค้า)

คุณอาจไม่ต้องใช้สำหรับเว็บไซต์การตลาด ไดเรกทอรีสาธารณะ หรือฟอร์มที่แค่ส่งอีเมลถึงคุณ รายชื่อรอไม่ต้องมีบัญชี มีช่องอีเมลก็พอ

วิธีล็อกอินที่พบบ่อยสี่แบบ

แอปหลายแอปผสมสองวิธีเข้าด้วยกัน การเข้าสู่ระบบด้วย Google บวกกับ magic link ทางอีเมลเป็นคู่ที่นิยม ครอบคลุมคนส่วนใหญ่โดยไม่ต้องเก็บรหัสผ่านใดเลย

อีเมลและรหัสผ่าน

หากคุณเสนอรหัสผ่าน ข้อบังคับเหล่านี้ไม่มีการต่อรอง:

• แฮชรหัสผ่านด้วยอัลกอริทึมการแฮชรหัสผ่านที่ช้า คำแนะนำการจัดเก็บรหัสผ่านของ OWASP แนะนำ Argon2id โดยมี scrypt, bcrypt หรือ PBKDF2 เป็นทางเลือก ห้ามเก็บรหัสผ่านเป็นข้อความธรรมดาหรือใช้แฮชทั่วไปที่เร็ว
• การรีเซ็ตรหัสผ่าน ใช้ลิงก์สุ่มที่ใช้ได้ครั้งเดียวและหมดอายุ ส่งไปยังอีเมลที่ยืนยันแล้ว
• อย่าเปิดเผยว่าอีเมลใดมีบัญชี ข้อความ "หากอีเมลนี้ลงทะเบียนไว้ เราได้ส่งลิงก์รีเซ็ตแล้ว" ดีกว่า "ไม่พบบัญชี"
• จำกัดอัตรา (rate-limit) การพยายามล็อกอินและรีเซ็ต เพื่อชะลอการเดารหัสผ่าน
• อนุญาตรหัสผ่านที่ยาวและตัวจัดการรหัสผ่าน และไม่ต้องใช้กฎที่บังคับให้มีอักขระผสมแปลก ๆ

Magic link และรหัสครั้งเดียว

magic link คือลิงก์เข้าสู่ระบบที่ส่งทางอีเมลให้ผู้ใช้ การคลิกจะล็อกอินให้ รหัสครั้งเดียวคือแนวคิดเดียวกัน แต่ให้พิมพ์แทนการคลิก

• ลิงก์และรหัสหมดอายุเร็วและใช้ได้เพียงครั้งเดียว
• ลิงก์ควรล็อกอินผู้ใช้บนอุปกรณ์ที่คลิก และโทเคนต้องไม่ค้างอยู่ในล็อกหรือเครื่องมือ analytics
• คุณต้องมีการส่งอีเมลที่เชื่อถือได้ ดู วิธีส่งอีเมลจากแอปของคุณ ทดสอบกับ Gmail และ Outlook และตรวจโฟลเดอร์สแปม

เข้าสู่ระบบด้วย Google (และ OAuth ของผู้ให้บริการอื่น)

"เข้าสู่ระบบด้วย Google" ใช้ OAuth และ OpenID Connect: Google ยืนยันว่าผู้ใช้คือใคร และบอกแอปของคุณถึงอีเมลและชื่อของผู้ใช้ การตั้งค่า ณ เดือนกันยายน 2026 ทำในส่วน Google Auth Platform ของ Google Cloud Console:

1. สร้างหรือเลือกโปรเจกต์ และกรอกหน้า Branding: สิ่งที่ผู้ใช้เห็นบนหน้าจอยินยอม (ชื่อแอป อีเมลฝ่ายสนับสนุน โลโก้)
2. ที่หน้า Clients สร้าง client ชนิด "Web application"
3. เพิ่ม authorized JavaScript origins และ redirect URI ซึ่งเป็นที่อยู่ที่แน่นอนที่แอปของคุณทำงาน และที่ Google ส่งผู้ใช้กลับไปหลังล็อกอิน
4. เก็บ client ID และ client secret ไว้ในความลับของแอป

ปัญหาที่พบบ่อยตามเอกสาร OAuth ของ Google:

• redirect_uri_mismatch: redirect URI ต้องตรงกันทุกตัวอักษร รวมถึง http กับ https ตัวพิมพ์ใหญ่เล็ก และ slash ท้ายสุด เพิ่มทั้งที่อยู่พรีวิวและโดเมนจริงของคุณ
• ต้องใช้ HTTPS: redirect URI ต้องใช้ HTTPS ยกเว้น localhost ระหว่างการพัฒนา
• พารามิเตอร์ state ควรถูกตรวจเมื่อกลับมา เพื่อป้องกัน cross-site request forgery ไลบรารีที่ดีจะทำให้โดยอัตโนมัติ

หากคุณขอเพียงข้อมูลพื้นฐานในการล็อกอิน (ชื่อ อีเมล โปรไฟล์) Google ระบุว่าไม่จำเป็นต้องผ่านการยืนยันแอป แต่การขอสิทธิ์เข้าถึง Gmail, Drive หรือ Calendar ของผู้ใช้เป็นเรื่องต่างออกไปและต้องผ่านการยืนยัน

สร้างเองหรือใช้ผู้ให้บริการ?

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

บทบาทและสิทธิ์

การล็อกอินบอกว่าใครเป็นผู้ใช้ สิทธิ์กำหนดว่าเขาทำอะไรได้ เริ่มจากเรียบง่าย:

กฎที่สำคัญกว่าชื่อบทบาท:

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

ทดสอบด้วยสองบัญชี: ล็อกอินด้วยบัญชีหนึ่ง จดรหัสของระเบียน จากนั้นล็อกอินด้วยอีกบัญชีแล้วลองเปิดระเบียนนั้น เช็กลิสต์ความปลอดภัย มีการทดสอบฉบับเต็ม

ความปลอดภัยของเซสชัน

หลังล็อกอิน แอปจดจำผู้ใช้ด้วยเซสชัน ซึ่งมักเป็นคุกกี้ แนวทางการจัดการเซสชันของ OWASP แนะนำ:

• ตั้งคุกกี้เซสชันด้วย Secure (HTTPS เท่านั้น) HttpOnly (สคริปต์ของหน้าอ่านไม่ได้) และ SameSite
• ออก session ID ใหม่เมื่อล็อกอิน และอีกครั้งเมื่อสิทธิ์เปลี่ยน
• มี idle timeout และอายุสูงสุดที่แน่นอน บังคับใช้ที่เซิร์ฟเวอร์
• การออกจากระบบจบเซสชันที่เซิร์ฟเวอร์ ไม่ใช่แค่ลบคุกกี้
• เซสชันถูกยกเลิกเมื่อผู้ใช้เปลี่ยนรหัสผ่าน

การเก็บโทเคนล็อกอินใน local storage ของเบราว์เซอร์เป็นเรื่องที่พบในบทเรียนทั่วไป แต่ทำให้โทเคนถูกเปิดเผยต่อสคริปต์ใด ๆ ที่รันบนหน้า คุกกี้ที่ปลอดภัยมักเป็นค่าเริ่มต้นที่ดีกว่าสำหรับเว็บแอป

พรอมต์ที่ครอบคลุมสิ่งจำเป็น

เพิ่มบัญชีผู้ใช้ให้แอปนี้ ผู้ใช้สมัครและล็อกอินด้วยอีเมลและรหัสผ่าน หรือด้วย Google ใช้ [library หรือ provider] แทนการเขียนโค้ดยืนยันตัวตนเอง แฮชรหัสผ่านด้วย Argon2id หรือ bcrypt เพิ่มการรีเซ็ตรหัสผ่านทางอีเมลด้วยลิงก์ที่ใช้ได้ครั้งเดียวและหมดอายุใน 1 ชั่วโมง เก็บเซสชันไว้ในคุกกี้ที่ปลอดภัยและ HttpOnly ป้องกัน /dashboard และทุกเส้นทาง /api ให้เฉพาะผู้ใช้ที่ล็อกอินใช้งานได้ และตรวจให้แน่ใจว่าผู้ใช้เห็นได้เฉพาะโปรเจกต์ของตัวเอง เพิ่มบทบาท "admin" ที่เห็นผู้ใช้ทั้งหมดได้ เฉพาะแอดมินเข้า /admin ได้ โดยตรวจที่เซิร์ฟเวอร์

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

ข้อผิดพลาดที่พบบ่อยในการล็อกอินที่สร้างด้วย AI

• การป้องกันอยู่แค่ในหน้า หน้าเว็บเปลี่ยนเส้นทางผู้ใช้ที่ยังไม่ล็อกอิน แต่ API ยังส่งข้อมูลให้ทุกคน
• ความลับในเบราว์เซอร์ client secret ของ OAuth และคีย์ผู้ดูแลของผู้ให้บริการยืนยันตัวตนต้องอยู่บนเซิร์ฟเวอร์
• URL พรีวิวกับ URL จริงสลับกัน redirect URI ของ Google หรือลิงก์อีเมลรีเซ็ตชี้ไปที่พรีวิว ทำให้การล็อกอินพังหลังเผยแพร่
• ไม่มีการยืนยันอีเมล ใครก็สมัครเป็น anyone@company.com ได้ ยืนยันอีเมลก่อนให้สิทธิ์ใดที่ผูกกับที่อยู่นั้น
• ทดสอบแค่กรณีปกติ ลองรหัสผ่านผิด ลิงก์ที่หมดอายุ และบัญชีที่สอง

การเพิ่มการล็อกอินใน Mythex

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

1. เลือกแนวทาง เช่น อีเมลและรหัสผ่านที่เก็บในฐานข้อมูลของคุณเอง หรือ SDK ของผู้ให้บริการแบบโฮสต์
2. หากคุณเก็บผู้ใช้เองคุณต้องมีฐานข้อมูล ขอได้ในแชตหรือใช้ /database
3. ใส่คีย์ของผู้ให้บริการในความลับของโปรเจกต์ (/secrets หรือการตั้งค่าโปรเจกต์)
4. ใช้พรอมต์ที่คล้ายด้านบน แล้วทดสอบใน Preview สำหรับการเข้าสู่ระบบด้วย Google ให้เพิ่ม redirect URI ทั้งสำหรับพรีวิวและที่อยู่ที่เผยแพร่แล้วของคุณ

ดู เพิ่มการล็อกอินให้แอปของคุณ ในเอกสาร หากคุณกำลังสร้างผลิตภัณฑ์แบบชำระเงิน วิธีสร้าง MVP ของ SaaS ครอบคลุมบัญชีและการเรียกเก็บเงินไปพร้อมกัน

คำถาม