Supabase Auth คืออะไร: ออกแบบระบบล็อกอินให้ SaaS ตั้งแต่วันแรก

ทีมที่เริ่มสร้าง SaaS ใหม่มักเจอทางแยกตั้งแต่สัปดาห์แรก คือจะเขียนระบบสมัครสมาชิก ล็อกอิน และจัดการ session เองทั้งหมด หรือใช้บริการสำเร็จรูปที่มีอยู่แล้ว การเขียนเองให้ความรู้สึกควบคุมได้เต็มที่ แต่ก็แลกมาด้วยเวลาหลายสัปดาห์ที่ควรเอาไปทำ core feature ของสินค้าจริง ๆ มากกว่า

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

บทความนี้จะอธิบายว่า Supabase Auth ทำงานยังไงในทางเทคนิค รองรับวิธีล็อกอินแบบไหนบ้าง และเมื่อออกแบบระบบสำหรับ SaaS ที่ต้องรองรับทั้งผู้ใช้เดี่ยวและทีมงานหลายคน ควรวางโครงสร้างยังไงตั้งแต่วันแรกเพื่อไม่ต้องรื้อทีหลัง

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

Supabase Auth ทำงานยังไงในทางเทคนิค

เมื่อผู้ใช้สมัครสมาชิกหรือล็อกอินสำเร็จ Supabase Auth จะสร้างระเบียนผู้ใช้ไว้ในตาราง auth.users ซึ่งเป็น schema พิเศษที่แยกจากตารางข้อมูลธุรกิจของแอป พร้อมออก JSON Web Token หรือ JWT กลับไปให้ client เก็บไว้ใช้ยืนยันตัวตนในการเรียก API หรือ query ครั้งถัดไป

จุดสำคัญคือ JWT นี้ไม่ได้ใช้แค่บอกว่า 'ใครล็อกอินอยู่' เท่านั้น แต่ยังถูกส่งไปพร้อมทุก query ที่ยิงผ่าน Supabase client library แล้วให้ Postgres อ่านค่า user id จากใน token นั้นไปใช้ตรวจสอบ Row Level Security policy อีกที ทำให้ระบบสิทธิ์ผูกกับการยืนยันตัวตนเป็นเนื้อเดียวกัน ไม่ต้องเขียน middleware ตรวจสิทธิ์แยกอีกชั้น

เมื่อ session หมดอายุ client library จะขอ refresh token ใหม่โดยอัตโนมัติผ่าน refresh token ที่เก็บไว้ ทำให้ผู้ใช้ไม่ต้องล็อกอินใหม่บ่อย ๆ ตราบใดที่ refresh token ยังไม่ถูกเพิกถอน

วิธีล็อกอินที่รองรับ และควรเลือกแบบไหน

Supabase Auth รองรับวิธียืนยันตัวตนหลายแบบ ซึ่งแต่ละแบบเหมาะกับกลุ่มผู้ใช้และลักษณะสินค้าต่างกัน

• อีเมล/รหัสผ่าน — คุ้นเคยที่สุดสำหรับผู้ใช้ทั่วไป แต่ต้องมีระบบยืนยันอีเมลและระบบลืมรหัสผ่านให้ครบ ไม่งั้นผู้ใช้ที่ลืมรหัสผ่านจะติดล็อกออกจากระบบถาวร
• OAuth ผ่านผู้ให้บริการภายนอก เช่น Google หรือ GitHub เหมาะกับ SaaS ที่กลุ่มเป้าหมายเป็นนักพัฒนาหรือคนทำงานที่มีบัญชีเหล่านี้อยู่แล้ว ลดขั้นตอนสมัครสมาชิกให้สั้นลงมาก
• Magic Link — ส่งลิงก์ล็อกอินทางอีเมลแทนรหัสผ่าน เหมาะกับสินค้าที่อยากลดความซับซ้อนของการจำรหัสผ่าน แต่ต้องพึ่งพาความเร็วของอีเมลที่ส่งถึง ถ้าอีเมลล่าช้าผู้ใช้จะหงุดหงิด
• OTP ผ่านเบอร์โทรศัพท์ — เหมาะกับตลาดที่ผู้ใช้คุ้นเคยกับการยืนยันผ่าน SMS มากกว่าอีเมล แต่มีต้นทุนค่าส่ง SMS ต่อครั้งที่ต้องคำนวณเข้าไปในต้นทุนดำเนินงาน

ออกแบบ Authentication สำหรับ SaaS ที่มีหลายทีม/หลายองค์กร

จุดที่ทีมพัฒนา SaaS มักออกแบบผิดตั้งแต่ต้นคือคิดว่า 'หนึ่งผู้ใช้ คือหนึ่งบัญชี' เหมือนแอปทั่วไป ทั้งที่ SaaS ส่วนใหญ่ต้องรองรับโครงสร้างแบบผู้ใช้หนึ่งคนอยู่ได้หลายองค์กร หรือหนึ่งองค์กรมีสมาชิกหลายคนที่มีบทบาทต่างกัน

วิธีที่ใช้ได้ผลจริงคือแยกตาราง auth.users (ที่ Supabase จัดการให้) ออกจากตาราง organizations และ organization_members ที่คุณสร้างเอง โดย organization_members เก็บความสัมพันธ์ระหว่าง user_id กับ organization_id พร้อมคอลัมน์ role เช่น owner, admin, member เพื่อกำหนดสิทธิ์การเข้าถึงข้อมูลแต่ละองค์กร

จากนั้นเขียน RLS policy บนตารางข้อมูลธุรกิจให้ตรวจสอบว่า user ปัจจุบันเป็นสมาชิกขององค์กรที่เป็นเจ้าของข้อมูลแถวนั้นหรือไม่ ก่อนอนุญาตให้อ่านหรือแก้ไข วิธีนี้ทำให้ข้อมูลของแต่ละองค์กรแยกจากกันอย่างปลอดภัยโดยไม่ต้องเขียน logic ตรวจสิทธิ์ซ้ำในทุก endpoint อ่านรายละเอียดเรื่องนี้เพิ่มได้ในบทความ Supabase RLS คืออะไร

จัดการ session และการเพิกถอนสิทธิ์ยังไงให้ปลอดภัย

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

Supabase Auth มีฟังก์ชันสำหรับเพิกถอน refresh token ของผู้ใช้เฉพาะราย ทำให้ session ที่ค้างอยู่ในอุปกรณ์อื่นถูกบังคับออกในการเรียก API ครั้งถัดไป ทีมที่ดูแลระบบควรมี flow นี้พร้อมใช้งานตั้งแต่ก่อน launch จริง ไม่ใช่คิดตอนเกิดเหตุการณ์ฉุกเฉินแล้วค่อยหาทางแก้

อีกจุดที่ควรวางแผนไว้คือการแจ้งเตือนเมื่อมีการล็อกอินจากอุปกรณ์หรือตำแหน่งที่ไม่คุ้นเคย ซึ่งไม่ใช่ฟีเจอร์ที่มาให้ฟรีในตัวเสมอไป แต่สามารถต่อยอดด้วย Edge Functions ที่ทำงานหลังผู้ใช้ล็อกอินสำเร็จ อ่านรายละเอียดเรื่อง Edge Functions ได้ในบทความ Supabase Edge Functions

ใช้ Custom Claims เพิ่มข้อมูลสิทธิ์เข้าไปใน JWT

บาง SaaS ต้องการให้ JWT พกข้อมูลเพิ่มเติมนอกเหนือจาก user id เปล่า ๆ เช่น role ปัจจุบันของผู้ใช้ในองค์กรที่กำลังใช้งานอยู่ หรือ plan ที่สมัครไว้ เพื่อให้ RLS policy หรือ logic ฝั่ง client ตรวจสอบได้เร็วโดยไม่ต้อง query เพิ่มทุกครั้ง

Supabase รองรับการทำ Custom Access Token Hook ที่ทำงานทุกครั้งก่อนออก JWT ให้ผู้ใช้ ทำให้แทรกข้อมูลเพิ่มเติม เช่น role หรือ organization ปัจจุบันเข้าไปใน token ได้ ก่อนตัดสินใจใช้วิธีนี้ควรพิจารณาว่าข้อมูลที่จะแทรกเข้าไปเปลี่ยนแปลงบ่อยแค่ไหน เพราะ JWT ที่ออกไปแล้วจะไม่อัปเดตข้อมูลใหม่จนกว่าจะ refresh รอบถัดไป

ถ้าข้อมูลเปลี่ยนบ่อยมาก เช่น role ที่อาจถูกเปลี่ยนกลางวันโดยแอดมิน การพึ่งพา custom claims ใน JWT เพียงอย่างเดียวอาจทำให้สิทธิ์ที่แสดงผลค้างอยู่จนกว่าจะ refresh token ควรมี query ตรวจสอบสิทธิ์ล่าสุดจากฐานข้อมูลจริงประกอบกันในจุดที่สำคัญ ไม่พึ่งแค่ค่าที่ฝังอยู่ใน token

เพิ่มความปลอดภัยด้วย Multi-Factor Authentication และการจำกัดความพยายามล็อกอิน

สำหรับ SaaS ที่จัดการข้อมูลธุรกิจสำคัญ การมีแค่รหัสผ่านอย่างเดียวมักไม่พอ Supabase Auth รองรับการเปิด Multi-Factor Authentication หรือ MFA ให้ผู้ใช้เพิ่มชั้นยืนยันตัวตนที่สองได้ เช่นผ่านแอปสร้างรหัส OTP บนมือถือ ซึ่งช่วยลดความเสี่ยงกรณีรหัสผ่านหลุดไปจากช่องทางอื่นที่ไม่เกี่ยวกับระบบของคุณเลย เช่นผู้ใช้ใช้รหัสผ่านเดียวกันซ้ำกับเว็บอื่นที่เคยถูกแฮ็ก

การตัดสินใจว่าจะบังคับ MFA กับผู้ใช้ทุกคนหรือเปิดเป็นตัวเลือก ขึ้นอยู่กับความเสี่ยงของข้อมูลที่ระบบจัดการ SaaS ที่เกี่ยวกับการเงินหรือข้อมูลลูกค้าจำนวนมากมักบังคับให้เปิดอย่างน้อยกับบัญชีระดับ owner หรือ admin ส่วน SaaS ทั่วไปอาจเปิดเป็นตัวเลือกให้ผู้ใช้เลือกเองว่าต้องการความปลอดภัยระดับไหน

อีกเรื่องที่ควรทำควบคู่กันคือจำกัดจำนวนครั้งที่พยายามล็อกอินผิดติดต่อกัน เพื่อป้องกันการเดารหัสผ่านแบบ brute force ถ้าไม่มีการจำกัดตรงนี้ ผู้ไม่หวังดีสามารถลองรหัสผ่านนับพันครั้งต่อวินาทีได้จนกว่าจะเจอรหัสที่ถูกต้อง ซึ่งเป็นความเสี่ยงที่ป้องกันได้ง่ายแต่มักถูกมองข้ามตอนออกแบบระบบครั้งแรก

• เปิด MFA แบบบังคับสำหรับบัญชีที่มีสิทธิ์สูง เช่น owner หรือ admin ขององค์กร
• จำกัดจำนวนครั้งที่ล็อกอินผิดติดต่อกัน แล้วล็อกบัญชีชั่วคราวหรือเพิ่มเวลารอก่อนลองใหม่
• แจ้งเตือนผู้ใช้ทางอีเมลเมื่อมีความพยายามล็อกอินผิดปกติ หรือมีการเปลี่ยนรหัสผ่าน/อีเมลของบัญชี

เทียบวิธีล็อกอินแต่ละแบบให้เลือกใช้ถูกจุด

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

ทำแบบนี้แล้วพัง เพราะอะไร

ข้อผิดพลาดที่พบบ่อยเมื่อทีมเริ่มออกแบบ Authentication สำหรับ SaaS ใหม่:

• ไม่แยกตาราง organization ออกจาก user ตั้งแต่ต้น — พอสินค้าต้องรองรับทีมงานหลายคนทีหลัง ต้องมา migrate โครงสร้างข้อมูลใหญ่ทั้งระบบ กระทบผู้ใช้ที่มีอยู่แล้ว
• เขียน logic ตรวจสิทธิ์ในโค้ด backend เองแทนที่จะใช้ RLS — ทำให้ทุก endpoint ใหม่ต้องเขียนการตรวจสอบซ้ำ เสี่ยงหลงลืมจุดใดจุดหนึ่งแล้วเปิดช่องข้อมูลรั่ว
• ไม่มี flow เพิกถอน session เมื่อจำเป็น — พอเกิดเหตุการณ์บัญชีถูกขโมยจริง ทีมไม่มีเครื่องมือบังคับ logout ผู้ใช้คนนั้นจากทุกอุปกรณ์ได้ทันที
• พึ่งพา custom claims ใน JWT สำหรับข้อมูลที่เปลี่ยนบ่อย — ทำให้สิทธิ์ที่แสดงผลไม่ตรงกับสถานะล่าสุดในฐานข้อมูลจริง

สรุป

Supabase Auth ช่วยตัดงานพื้นฐานของระบบล็อกอินออกไปได้มาก แต่การออกแบบโครงสร้างข้อมูลสำหรับ SaaS ที่รองรับหลายองค์กรและหลายบทบาทยังเป็นหน้าที่ของทีมพัฒนาที่ต้องวางแผนเอง การแยกตาราง organization ออกจาก user ตั้งแต่วันแรก จะช่วยประหยัดเวลามหาศาลเมื่อสินค้าต้องรองรับทีมงานในอนาคต

สิ่งที่ควรทำก่อน launch จริงคือทดสอบ flow ที่มักถูกมองข้าม เช่น ลืมรหัสผ่าน เพิกถอน session และการจัดการสิทธิ์เมื่อมีคนออกจากทีม เพราะ flow เหล่านี้มักไม่ถูกทดสอบตอนพัฒนาฟีเจอร์หลัก แต่กลับเป็นจุดที่ผู้ใช้จริงเจอปัญหาบ่อยที่สุด

• Supabase Auth ผูก JWT กับ RLS ทำให้ระบบสิทธิ์เป็นเนื้อเดียวกับการยืนยันตัวตน
• แยกตาราง organization ออกจาก user ตั้งแต่ต้นเพื่อรองรับ SaaS แบบหลายทีม
• เตรียม flow เพิกถอน session และลืมรหัสผ่านให้พร้อมก่อน launch จริง

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