ทำไมคุณไม่ควรสร้างระบบยืนยันตัวตนของตัวเอง: บทเรียนจากสิบๆ การสัมภาษณ์ลูกค้า

ระบบยืนยันตัวตนดูเหมือนจะเป็นสิ่งที่คุณสร้างเองได้ง่าย ๆ อีเมล รหัสผ่าน แฮชมัน แล้วเทียบตอนล็อกอิน มันจะยากอะไรแค่ไหนกับการสร้างระบบยืนยันตัวตนเอง?

คุณทำได้ นั่นคือกับดัก

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

แต่ละอุตสาหกรรม, เทคโนโลยี, และขนาดทีมต่างกัน แต่มักจบแบบเดียวกัน ระบบยืนยันตัวตนที่สร้างขึ้นกลายเป็นหนี้สินที่ทีมต้องแบกไว้

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

สัปดาห์ก่อนมันยัง "โอเค" จากนั้นสิ่งถัดไปใน roadmap ก็ติดอยู่กับมัน

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

การยืนยันตัวตนไม่ใช่ฟีเจอร์ แต่มันคือโครงสร้างพื้นฐานด้านตัวตน

เบื้องหลังหน้าล็อกอินคือโมเดลตัวตนทั้งระบบ#

ทุกระบบยืนยันตัวตนที่สร้างเองล้วนเริ่มต้นเหมือนกัน รับอีเมลและรหัสผ่าน แฮชแล้วเก็บ เทียบตอนล็อกอิน โค้ดสี่สิบบรรทัด สะอาดเรียบร้อย

ปัญหาเริ่มหลังจากปล่อยใช้งานจริง บอทถล่ม endpoint สมัครสมาชิก คุณก็ต้องใส่ rate limit, CAPTCHA, การแยกแยะอุปกรณ์ อีกเช้าระบบ SMS ส่งโค้ดไม่ออก คุณก็ไปเพิ่มระบบ retry และจำกัดจำนวนครั้ง/วัน จากนั้นงานที่ยากขึ้นก็ตามมา: ระบบรีเซ็ตรหัสผ่านอย่างปลอดภัย, MFA และ Flow กู้บัญชี, เซสชันกับรีเฟรชโทเคน, และโมเดล permisssion ที่ซับซ้อนกว่าแค่ is_admin boolean

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

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

แต่ละฟีเจอร์ที่เขียนต่อจากนั้นก็อาศัยคำตอบเหล่านั้นไป, และยิ่งระบบรันมานาน แก้ไขก็ยิ่งยากขึ้น

เราเห็นเรื่องนี้เกิดจริงที่บริษัทหนึ่ง: SaaS B2B แนวตั้ง, อยู่มา 20 ปี, ให้บริการธุรกิจหน้าร้าน พวกเขาสร้าง auth เองมากว่าทศวรรษ มีระบบล็อกอินแยกต่อรายลูกค้า permission ฝังกระจายอยู่ใน business module ตอนนั้นมันดูสมเหตุสมผล

ยี่สิบปีต่อมา สิ่งที่ต้องการคือ "หน้าล็อกอินรวม" ใช้อีเมลเป็นชื่อผู้ใช้ ฟังดูเล็กน้อยแต่ไม่ใช่แค่การเปลี่ยนหน้าเว็บ เพราะ logic เฉพาะกระจายอยู่ในร้อย ๆ module การรวมล็อกอินจึงกลายเป็นต้องไปแตะทั้ง user model, org model, migration credential และขอบเขต permission ทั้งหมด สุดท้ายไม่มีใครอยากเซ็นรับ ก็เลยยืดเวลาออกไปเป็นปี

เมื่อเขียน login page ครั้งแรกมันเหมือนแค่ฟีเจอร์ แต่สิ่งที่ทิ้งไว้ข้างหลังคือโมเดลตัวตนทั้งชุด

เมื่อธุรกิจขยาย, auth ที่ทำเองก็เริ่มไม่เพียงพอ#

พูดตามตรง, auth ที่ทำเองมักจะรันได้ยาวนาน มันล็อกอินผู้ใช้, refresh session, และขับเคลื่อนธุรกิจปีต่อปี ความซับซ้อนเพิ่มขึ้นช้า ๆ ทีละนิด คุณก็แก้ทีละจุดด้วยความมั่นใจว่าคุมได้

แต่การบอกว่า "เพียงพอ" ส่วนมากแปลว่าธุรกิจยังไม่ชนกำแพงเท่านั้น พอวันนั้นมาถึง ปัญหามักไม่ได้เกิดที่ auth โดยตรง แต่มันคือธุรกิจรอบข้างเปลี่ยนไป และ "เพียงพอ" ก็กลายเป็น "ขวางทาง" ทันที

สถานการณ์ตัวอย่างเหล่านี้เกิดขึ้นแทบทุกโปรดักต์เมื่อขยายตัว ทั้งหมดดูต่างกัน แต่แก่นแท้คือนี่: ธุรกิจเดินไปข้างหน้า แต่ identity model เดิมไปไม่ไหว

ลูกค้าองค์กรขอ SSO#

โจทย์: ลูกค้าต้องการล็อกอินด้วย IdP ของตัวเอง แต่ระบบ auth คุณไม่รู้จัก "identity provider ของคนอื่น" เลย

ดีลลูกค้าองค์กรรายแรกมาถึง ฝ่ายจัดซื้อส่งเอกสาร requirement มา เริ่มที่ SSO ผ่าน Microsoft Entra หรือ Google Workspace ถัดมาคือทั้ง SAML และ OIDC เพราะลูกค้ารายต่อไปใช้แบบอื่น เพิ่ม SCIM ให้ provision/deprovision พนักงานอัตโนมัติ

แต่ละบริษัทเซ็ตอัพต่าง workflow, โปรโตคอล, mapping ฟิลด์, ตารางอายุใบรับรอง, mapping โครงสร้างองค์กร

และแทบไม่มีงานไหน reuse ได้ ลูกค้ารายใหม่มาก็ IdP ใหม่ เซ็ตใหม่เกือบหมด SSO ไม่ใช่ฟีเจอร์ที่สร้างแล้วจบ ทุกครั้งที่คุณ signed ลูกค้าองค์กร, คุณ build อีกรอบ และต้นทุนก็เพิ่มขึ้นตามจำนวนนั้น

Auth ไม่ได้แค่ "ให้ผู้ใช้ล็อกอินแอปคุณ" อีกต่อไป แต่คือ "ให้แอปคุณเชื่อมกับ identity system ของลูกค้า" กลายเป็นงานสองแบบที่ต่างกันสุดขั้ว

เจอเคสบริษัทหนึ่ง ที่ SSO ทั้งหมดเซ็ตมือหมด และมีวิศวกรคนเดียวเท่านั้นที่เข้าใจแบบ end-to-end ถ้าเขาอยู่ ลูกค้าขึ้นระบบได้ ถ้าไม่อยู่ ฝ่ายขายกับ onboarding ก็ติดคิว ถ้าเขาออก ความรู้ก็จากไปด้วย

ไม่มีเรื่องนี้ในวันแรกที่ตัดสินใจสร้าง auth เองเลย

โปรดักต์ต้องการรวม identity ที่กระจายกันหลายระบบ#

โจทย์: ข้อมูลตัวตนแตก fragmentation ตามองค์กรและแต่ละโปรดักต์ และเมื่อธุรกิจขยายก็ต้องการ identity รวมเดียว

บริษัท 20 ปีข้างต้นเจอประเด็นนี้ตอนรวมล็อกอิน และเคสแบบนี้พบได้ทุกที่ เราเคยร่วมงานกับแพลตฟอร์มที่มี 9 โปรดักต์มาจากการควบรวม ก็ต่างแยก auth และ store ผู้ใช้ของตัวเอง

การควบรวมกิจการไม่ได้รวม auth ให้คุณ ทุกโปรดักต์คืออีก auth stack และการดูแล auth 9 ก้อนขนานกัน ต้องใช้คนจำนวนจริงจัง

คำถามเริ่มกองโต: คนเดียวกันนับเป็น user เดียวหรือสองคนข้ามโปรดักต์? จะ map องค์กรลูกค้าเดียวกันข้าม 2 ระบบอย่างไร? สิทธิ์ข้ามโปรดักต์ตรวจสอบยังไง? ถ้าพนักงานลาออก ถอนสิทธิ์ออกจาก 9 โปรดักต์พร้อมกันยังไง? จะ audit อะไรได้บ้าง?

แต่ละ auth ไม่ได้พัง ร่วมกันแล้วมันคือ wall

"รวม identity" ดูเหมือนแค่ฟีเจอร์ แต่ในโค้ดคือการนิยามใหม่ของพื้นฐานสุด: อะไรคือนิยาม "user" และ "org" ทุกฟีเจอร์บน ๆ พิงตรงนี้หมดย้ายแล้วต้องถอดหมด

ยุค AI: agent และ CLI เข้าถึงระบบในนามผู้ใช้#

โจทย์: ไม่ใช่แค่คนล็อกอินจาก browser อีกต่อไป แต่ agent, CLI, script ต่างก็อ้างว่าทำแทนผู้ใช้ ขณะที่ auth ของคุณรู้จักแค่การล็อกอินผ่านหน้าเว็บ

agent ต้องเรียก internal tools ในนาม user, MCP server ต้องเปิด resource แบบป้องกัน, CLI ต้อง retrieve ข้อมูล account โดยไม่มี browser

สามอย่างนี้ต้องการคำตอบเดียวกัน: request นี้แทนใคร, แตะ resource อะไรได้, token ออกให้ใคร, มีขอบเขตอะไร, ถอน revoke ยังไง, log ว่าเป็น user หรือ agent

ระบบเก่าไม่ได้สร้างกลไกเพื่อรองรับเหล่านี้ MCP พึ่ง OAuth issue authorization CLI ต้อง login ผ่าน OAuth หรือใช้ personal access token แทนคน เพื่อให้สามารถ revoke ได้ตลอดเวลา ซึ่งไม่มีอะไรทำมาเพื่อหน้า login page เลย

หาก auth คุณออกแบบรอบ user คนเดียว login หน้าเว็บ ตอนนี้คือต้อง handle client ที่มาแทน user

การดูแลระยะยาวคือต้นทุนใหญ่สุดของ auth แบบทำเอง#

ทุกสถานการณ์ข้างบนไม่ใช่ "auth ล่ม" ระบบยังรันอยู่ แต่ละฟีเจอร์ดูเล็ก ๆ ทันทีที่เริ่มทำ กลายเป็นเรื่องกลยุทธ์โปรดักต์, data migration และงานส่งมอบให้ลูกค้า

MFA คือตัวอย่างชัด ๆ ตอนแรกแค่ "ขอ verify อีกรอบหลัง login" แต่สองขั้นต่อมาคือ: บังคับ org/user ไหนได้แค่ไหน, admin บังคับลูกทีมได้ไหม, action สำคัญอย่างเปลี่ยนข้อมูลจ่ายเงิน/export data ต้อง re-check เพิ่มอีกไหม, recovery code สร้าง/reset อย่างไร, support ช่วย reset ได้ไหม, MFA ของ user SSO เป็นของคุณหรือของ IdP ลูกค้า? เพิ่ม MFA จึงเหมือนเพิ่ม layer policy ความปลอดภัยทั้งชุด

"แค่ซิงค์ user" ก็เหมือนกัน ข้างหลังคือชุดข้อสรุป onboarding, offboarding, cross-org membership ที่ล้วนต้องออกแบบ user/org model ให้ถูกตั้งแต่แรก

ยิ่งเพิ่มฟีเจอร์ คุณก็ยิ่งดูแลผลิตภัณฑ์ identity อยู่ข้างในโปรดักต์ตัวเอง เวอร์ชันแรกถูก ใช้วิศวกรไม่เยอะ เวลาไม่เยอะ แต่หลังจากนั้นคุณต้องเลี้ยงดูมันปีแล้วปีเล่า

ต้นทุนที่ซ่อนอยู่: ค่าใช้จ่ายเปลี่ยนรูปแบบการจ่าย#

เหตุผลยอดนิยมที่สร้าง auth เองคือเรื่องต้นทุน, ไม่ใช่ความคิดที่ผิด

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

ห้าปีต่อมา คณิตศาสตร์กลับด้าน: แค่ดูแลล็อกอินและความปลอดภัย auth เอง รวมทุกอย่างแพงกว่าการซื้อสำเร็จรูปเสียอีก

ปีแรก invoice ที่ประหยัดคือเงินที่มองเห็น เวลา engineer ที่เสียไปมองไม่ออก พอถึงปีห้า invoice ที่หลบไว้ตัวเลขเท่าเดิม แต่วิศวกรเสียเวลาติด roadmap, หนี้ความปลอดภัย, งานบำรุงที่ไม่มีใครอยากสานต่อ

ดังนั้น auth ที่สร้างเองไม่ฟรี คุณแค่ไม่มี invoice "subscription ระบบยืนยันตัวตน" เท่านั้นเอง แต่ต้องจ่ายด้วยเดือนงานวิศวกร, deadline ที่ช้า, rework, หนี้ความปลอดภัย, และ resource ที่ควรเอาไปลงโปรดักต์หลักแทน

ไม่กี่วิศวกรกลายเป็นเจ้าของระบบ#

วิศวกรเซ็ต SSO มือเดียวในตัวอย่างไม่ใช่เรื่องแปลก ๆ ถ้า auth ทำเองนานพอ, context ทั้งระบบจะไปกองบนคนหนึ่งหรือสองคน: ลูกค้าคนไหนเซ็ตแบบไหน, ฟิลด์ไหนห้ามแตะ, migration อะไรผ่านมาเพราะอะไร ข้อมูลพวกนี้แทบไม่ลง doc อยู่ในหัวของคนเท่านั้น

ถ้าเขามีคนอยู่ งานเดิน ถ้าไม่อยู่ ฝ่าย sales/enterprise ติด pipeline สุดท้ายโครงสร้างสุดสำคัญในธุรกิจไม่มีคนเป็นเจ้าของ มีแค่ "คนที่รู้"

บางทีมไปถึงขั้นสร้าง platform ให้ลูกค้า configure SSO เองทั้งหมด ดูเหมือน mature ถามจริง ๆ มีลูกค้าใช้กี่ราย? เคยเห็นที่หนึ่ง user 1.5 ล้าน/เดือน แต่ระบบนี้ serve ลูกค้าแค่สิบสองราย

คุณคิดว่าสร้างฟีเจอร์ ที่จริงสร้าง product ภายใน ค่าใช้จ่ายกระจายกับลูกค้าไม่กี่ราย ถ้า identity คือ core business ของคุณถือว่าคุ้ม แต่ถ้าไม่ใช่ นั่นคือบิลที่ซ่อนแบบ real

คุณอยากให้วิศวกรคุณทำงานตรงไหน?#

กลับไปบริษัท SaaS 20 ปี ไม่ใช่วิศวกรที่อ่อนประสบการณ์แน่ ๆ รักษา software อุตสาหกรรมไว้ยี่สิบปีได้แบบนี้คือผู้รู้ลูกค้าดี

แต่ทั้งหมดนี่คือต้นปัญหา พูดแรง ๆ คือ จะให้เขากู้ permission logic 20 ปีออกจากร้อย module หรืออยากให้เขาพัฒนาซอฟต์แวร์อุตสาหกรรมลึกลงไปอีก?

นี่ไม่ใช่เพอร์เฟ็กชันนิสต์ แต่มันคือ resource allocation ถ้าคุณทำ bill pay, vertical SaaS, portal สมาชิก, โซลูชั่น operation ไม่มีลูกค้าคนไหนจ่ายเพิ่มเพราะคุณเขียน OAuth server เอง

ทีม bill pay ทีมหนึ่งที่เราเจอพูดตรง ๆ: IdP ที่สร้างเองนั้น "fine" แต่เป็นเรื่อง strategy อย่าเขียน auth มากกว่าจำเป็น เอาแรงไปพัฒนา bill pay ให้สุด ใช้ auth คุณภาพตลาดสำหรับงานที่เหลือ

auth ต้องน่าเชื่อถือ แต่คำว่า "น่าเชื่อถือ" ไม่ใช่ต้องเขียนเอง database, ส่งอีเมล, cloud, ก็ต้องเชื่อถือได้ทั้งนั้น ทีม mature ไม่ assume ว่าสิ่งสำคัญต้องดูแลเองเสมอไป

สำหรับโปรดักต์ส่วนใหญ่ auth คือ dependencies สำคัญไม่ใช่ตัว create ความต่าง เว้นแต่ identity คือธุรกิจคุณจริง ๆ การสร้างระบบ identity ภายในคือ drag ทรัพยากรระยะยาว

เมื่อไหร่ที่การสร้าง auth เองจึงเหมาะสม?#

ข้อผิดพลาดที่ง่ายคือคิดว่าห้ามเขียน auth code เลย ซึ่งไม่ถูก

ในบางเฟส การสร้างเอง (หรือสร้างแค่บางส่วน) เป็นข้อดี เช่น เดโมภายใน, โปรโตไทป์ต้นแบบ, validate product ครั้งเดียว หรือกรณี business ต้องการ auth/authorizations เฉพาะกลุ่มที่สำเร็จรูปตอบโจทย์ไม่ได้ ในกรณีแบบนี้สร้างเองส่วน authorize, แล้วใช้ external สำหรับระบบ authentication, session, SSO, MFA, user directory ก็โอเค

อย่าพลาด slope POC เคยเจอเส้นทางคลาสสิก: dev สองคนสร้าง prototype external integration ใช้เวลา 6-8 เดือน approach ไม่แย่ ของที่ได้ก็ดีมาก แต่ออกแบบมาไม่ได้ใช้ scale จริงเลย

และ POC คือของที่ทำให้กลายเป็นระบบจริงได้ง่ายมาก หกเดือนถัดมาคือ "solution ปัจจุบัน" สองปีถัดมา "ระบบ legacy" ห้าปีต่อมา "infrastructure ที่แตะไม่ได้" เวลาถอน auth แบบทำเองที่ดีที่สุดไม่ใช่หลังมันพัง แต่คือก่อนมันกลายเป็น core layer

ดังนั้นเส้นแบ่งคือ: อย่าดูแค่การเขียน auth code แต่ถามว่าคุณกำลังดูแลชิ้นส่วน identity infrastructure ระยะยาวในทีมตัวเองแบบเงียบ ๆ หรือเปล่า

build ความสามารถเฉพาะที่จำเป็นเอง ระวัง core identity layer และอย่าสร้าง CIAM platform โดยไม่รู้ตัว

ถ้าไม่สร้างเองจะเลือก auth solution อย่างไร?#

ถ้าคิดจะไม่เขียนเอง คำถามถัดมาคือ: จะซื้อของใคร และเลือกยังไง?

solution ที่ mature ส่วนใหญ่มีทุกฟีเจอร์: SSO, MFA, multi-org, unified login, agent access ส่วนใหญ่ความต่างไม่ได้อยู่ที่ฟีเจอร์

สิ่งที่คนมองข้ามและควรเปรียบเทียบจริง ๆ มี 4 ข้อนี้ สาระคืออย่าหนีจาก coode พันบรรทัดของคุณ ไปติด vendor lock-in ระบบใหม่

• ยึดมาตรฐาน protocol อย่าสร้าง stack เองหรือเจาะ vendor เดียว OIDC, OAuth และ JWT แบบ RS256 เป็นมาตรฐานที่ dev เข้าใจอยู่แล้ว อ่าน claims ออกจาก token เดิม ๆ ได้เลย ไม่ต้องพึ่ง API เฉพาะของ vendor
• ให้มีประตูออกได้เสมอ ถ้า open source/self-host ได้จะย้ายตอนไหนก็ได้ (แน่นอนว่า self-hosting มี maintenance cost เอง)
• อย่าให้ billing tracked by user table การคิดราคาตาม registered user หรือใช้งานจริงต่อเดือนคือ table ที่มีแต่โตเต็มไปด้วยผู้ใช้ที่ไม่ล็อกอินอีกต่อไป ถ้า scale กลายเป็น "growth tax" นี่แหละคือราคาที่ผลักให้องค์กรมาก่อนสร้าง auth เอง
• ข้อมูลคุณออกได้เสมอ export user data ได้เองเสมอ การฝากข้อมูล sensitive กับ host ที่ชำนาญจะลดความเสี่ยงที่ควรเป็นเจ้าของข้อมูลส่วนตัวไว้เอง

เปิดเผยเต็มที่: Logto เป็นระบบ auth ที่เราสร้างมาเพื่อตอบโจทย์ทั้งสี่นี้ มัน open source, self-host ได้ และมีเวอร์ชัน Cloud ให้เลือก - ใช้ Cloud ไม่ต้องดูแลเลย หรือ self-host คุมเอง 100% พร้อมย้ายออกได้วันไหนก็ได้

Sign-in, MFA, SSO, RBAC พร้อมใช้ตามมาตรฐาน OIDC billing แบบนับ tokens ใช้เท่าไรจ่ายเท่านั้น

แน่นอนว่ามีตัวเลือกอื่นอีกมาก และ auth ไม่เคยมีคำตอบเดียว ถ้ายังเลือกอยู่ ลองอ่าน แนวทางเลือก auth solution ที่ผมเขียนไว้ได้

สรุป: อย่าสับสน identity platform ระยะยาวกับฟีเจอร์ธรรมดา#

auth แบบทำเองมักดูสมเหตุผลในวันแรก แต่กับดักอยู่ที่มันจะโตเป็น infrastructure ภายหลัง

ทุกครั้งที่ธุรกิจโตขึ้น identity platform จะถูกขุดมาใช้อีก: enterprise ขอ SSO, security ขอ MFA, โปรดักต์อยากรวม login, หลายโปรดักต์เชื่อมต่อกัน, AI agent ขอสิทธิ์เข้าถึง user หลังฟีเจอร์เล็ก ๆ ทุกอัน คือบท policy ที่จะกลืนเวลาด้านวิศวกรที่ควรใช้กับโปรดักต์หลัก

บิลนี้ไม่มาวันแรก แต่มาทีหลังเมื่อสายไป มองย้อนจึงเห็น: หน้า login ที่คุณเขียนวันนั้นคือ identity infrastructure ที่รันอยู่ทุกวันตลอดชีวิตโปรดักต์

auth อาจไม่ใช่ core ธุรกิจคุณ ยิ่งเห็นชัดเร็วเท่าไร คุณจะยิ่งเอาหัวใจ เวลาทรัพยากร กลับไปลงในโปรดักต์ที่สร้างจริงๆ

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

ควรไม่สร้าง auth เองเลยหรือไม่?#

ไม่จำเป็น เดโมต้นแบบ, เครื่องมือภายใน, งาน validate รายครั้ง, หรือ authorize แบบละเอียดที่ของสำเร็จรูปตอบไม่ได้ก็สร้างเองได้ สิ่งควรหลีกเลี่ยงคือเอา identity infrastructure ทั่วไปมาฝากไว้กับทีม dev ระยะยาวแบบไม่รู้ตัว

ความต่างของ authentication และ authorization คืออะไร?#

authentication ตอบว่า "คุณเป็นใคร" authorization ตอบว่า "คุณทำอะไรได้" ใน SaaS จริง ๆ ทั้งคู่อยู่คู่กัน: user, org, role, permission, session, token claim, audit log ทุกอย่างพันกันเปลี่ยน auth system จึงเปลี่ยนแค่หน้า login ไม่พอ

ทำไม enterprise SSO ทำให้ auth แบบทำเองซับซ้อน?#

เพราะต้องทำให้แอปคุณเชื่อมกับ identity ของลูกค้าได้ ลูกค้าแต่ละรายใช้ IdP/protocol/claim/certificate/โครงสร้าง org mapping ต่างกัน กำหนดลูกค้าแรกผ่านได้ ไม่หมายความว่างานถัดไปคือ copy&paste ส่วนใหญ่งานกลายเป็น manual ที่คนเดียวเข้าใจ

ถ้าระบบ auth ของเราใช้งานเองมาหลายปี ยังสามารถย้ายระบบได้ไหม?#

ได้ แต่การ migrate ทีเดียวมักไม่ดีที่สุด ทำเป็น layer: ลง platform ใหม่กับ user ใหม่/enterprise SSO ก่อน ส่วน user เก่าค่อย migrate เมื่อ login ถัดไป เก็บ rollback/audit log ไว้เสมอ migration จะ reversible ตลอดเวลา