คุณสร้างระบบ auth เองได้ในวันเดียว แต่นั่นแหละคือกับดัก
ทีม B2B หลายสิบทีมเล่าเรื่องเดียวกันให้เราฟัง มันเริ่มต้นแค่หน้าล็อกอินธรรมดา ก่อนที่ทราฟฟิกจริงจะไหลเข้ามา แล้วมันค่อย ๆ กลายเป็นโครงสร้างตัวตน ซึ่งเป็นรากฐานที่ผลิตภัณฑ์ของคุณตั้งอยู่
มันดูเหมือนฟีเจอร์ธรรมดา แต่มันทิ้งโมเดลตัวตนทั้งระบบไว้เบื้องหลัง
ทุก auth ที่สร้างเองเริ่มจากโค้ดไม่กี่บรรทัด แต่ปัญหาเริ่มหลังจากเปิดใช้งาน เมื่อแต่ละการตัดสินใจย่อย ๆ ค่อย ๆ กลายเป็นโมเดลหลักที่ทั้ง product ต้องอาศัย
วันแรก: สี่สิบบรรทัดโค้ด
อีเมล รหัสผ่าน แฮช เก็บเปรียบเทียบตอนล็อกอิน จบครบ
วันที่สองร้อย: โมเดลตัวตนแบบเงียบ ๆ
ใครนับว่าเป็นผู้ใช้ สังกัดองค์กรไหน session ไหนยังเชื่อถือได้ ใครเป็นคนดึงสิทธิ์ออก
ปีที่ห้า: ฐานรากที่คุณแตะไม่ได้
การเปลี่ยน login page บนกระดาษเท่ากับต้องรื้อ identity foundation ในโค้ดใหม่
Auth ที่สร้างเองทำงานได้ดี — จนวันที่ธุรกิจเปลี่ยน
มันล็อกอิน คนเข้าระบบได้ไม่มีปัญหาหลายปี แต่การเปลี่ยนแปลงธุรกิจแค่ครั้งเดียว ก็ทำให้ “พอใช้” กลายเป็น “กลายเป็นอุปสรรค” ขึ้นมาทันที สามจุดนี้เกิดขึ้นแทบทุก product ที่ scale
ลูกค้าองค์กรเริ่มขอ SSO
ดีลใหญ่รายแรกมาต้องการ SSO ผ่าน Entra หรือ Google Workspace ของตัวเอง ต่อมาก็ต้องรองรับทั้ง SAML และ OIDC เพราะลูกค้ารายถัดไปใช้แบบอื่น แต่ละลูกค้ามีระบบตัวตนต่างกันแทบทั้งหมด และงานแทบไม่มีส่วนไหนใช้ซ้ำกันได้เลย
- แต่ละลูกค้ามี protocol, การ mapping field, การเปลี่ยน certificate แตกต่างกัน
- SSO ไม่ใช่สร้างครั้งเดียว แต่ต้องทำใหม่ทุกครั้งเมื่อลูกค้า enterprise ใหม่มาถึง
- ท้ายที่สุดกลายเป็นภาระงานที่มีวิศวกรบางคนรู้กระบวนการทั้งหมดเพียงคนเดียว
ตัวตนที่กระจายต้องรวมเป็นหนึ่งเดียว
แยกตามองค์กร แยกตาม product หรือสืบทอดมาจากการควบรวมกิจการ “รวมตัวตน” ฟังดูเหมือนแค่ฟีเจอร์ แต่ในโค้ดคือการนิยามใหม่ว่าหนึ่ง user หรือหนึ่งองค์กรคืออะไร
- อีเมลเดียวกันอยู่ได้หลายองค์กรหรือไม่ ย้าย username เดิมอย่างไร
- ควบรวมจาก 9 product คือ 9 auth stack ทำงานขนานกัน
- ต้องเพิกถอนสิทธิ์สำหรับผู้ลาออกในทุกระบบพร้อมกัน และตรวจสอบย้อนกลับได้ในที่เดียว
AI agent และ CLI เริ่มดำเนินการแทนผู้ใช้
ตอนนี้ไม่ใช่แค่คนใช้งานในเบราว์เซอร์แล้ว agent, MCP server และ command line ต่าง ๆ ก็ขอสิทธิ์แทนผู้ใช้ แต่ auth ของคุณอาจรู้แค่จะล็อกอินคนเข้าสู่หน้าเว็บอย่างเดียว
- token ถูกออกให้ใคร มี scope และ audience แบบใด
- อนุญาตให้แค่เครื่องมือเดียวหรือข้อมูลชุดย่อย แล้วเพิกถอนสิทธิ์เมื่อไหร่ก็ได้
- MCP และ CLI เน้น OAuth ไม่ใช่แบบฟอร์มล็อกอิน
ต้นทุนที่แท้จริงไม่ใช่ช่วงที่สร้าง แต่คือการดูแลมันไปหลายปี
เวอร์ชันแรกสร้างง่าย แค่ไม่กี่วิศวกร ไม่กี่สัปดาห์ก็จบ แต่หลังจากนั้นคุณต้องเสียเวลาที่ควรพัฒนาผลิตภัณฑ์หลักไปดูแล auth นี้ทุกปี
บิลไม่ได้หาย แค่เปลี่ยนวิธีจ่าย
คุณจะไม่ได้รับใบแจ้งหนี้ที่บอกว่า “authentication”
สุดท้ายพึ่งแค่คนหนึ่งหรือสองคน
บริบทสำคัญอยู่ในหัวคน ไม่ใช่เอกสาร
คุณอยากให้วิศวกรของคุณอยู่ตรงไหน
ไม่มีลูกค้าคนไหนยอมจ่ายเพราะคุณเขียน OAuth server เอง
ถ้าไม่สร้างเอง แล้วควรเลือกอย่างไร
auth ที่ครบเครื่องส่วนใหญ่รองรับ SSO, MFA, องค์กร, unified login, agent access อยู่แล้ว สิ่งสำคัญคือคุณย้ายออกได้ไหม อย่าสร้างระบบขึ้นมาเองนับพันบรรทัดแล้วต้องติดกับ vendor รายใหม่
มาตรฐานสากล ไม่ใช้ stack ที่คิดเอง
ประตูที่ออกได้จริง
ระบบคิดเงินที่ไม่ผูกกับ user table ของคุณ
ข้อมูลของคุณไม่เคยถูกล็อกไว้
auth อาจไม่ใช่ธุรกิจหลักของคุณ — ให้ความสำคัญแค่นั้นก็พอ
Logto เป็น open source, self-host ได้ และยังมีแบบ Cloud สำเร็จรูป พร้อม sign-in, MFA, SSO, RBAC ใช้งานได้ทันทีผ่านมาตรฐาน OIDC ระบบคิดเงินตาม token วันที่คุณอยากเปลี่ยนออก ประตูก็เปิดเสมอ