ถ้าคุณเคยดูราคาของแพลตฟอร์ม CIAM แบบ SaaS บางเจ้า คุณคงสังเกตแล้วว่าค่าใช้จ่ายพุ่งสูงแค่ไหน และน่าจะเคยคิดถึงทางเลือกแบบโฮสต์เอง
บทความนี้ว่าด้วยแพลตฟอร์ม CIAM แบบโฮสต์เองสี่ตัวที่ทีม B2B SaaS ขนาดเล็กดูแลได้จริงโดยไม่กลายเป็นงานประจำที่สอง ได้แก่ ZITADEL, FusionAuth, Logto และ Ory Hydra ทั้งสี่ไม่ได้มีรูปแบบเหมือนกัน และตัวที่เหมาะกับคุณขึ้นอยู่กับชนิดของผลิตภัณฑ์ B2B ที่คุณกำลังสร้างมากกว่ารายการฟีเจอร์ ผมรันทั้งสี่ตัวคู่กันบน VPS เครื่องเดียวเป็นเวลาหนึ่งสัปดาห์เพื่อทำการเปรียบเทียบนี้ และสิ่งที่ตามมาคือเวอร์ชันที่ผมจะส่งให้ผู้ก่อตั้งที่ทัก DM มาถามเรื่อง CIAM
ขอบอกไว้ก่อน: บทความนี้พูดถึง CIAM ในฐานะฟีเจอร์ของผลิตภัณฑ์ ไม่ใช่ SSO ภายในสำหรับทีมของคุณเอง
เวอร์ชันสั้น
แพลตฟอร์ม CIAM แบบโฮสต์เองสี่ตัว สรุปตัวละหนึ่งบรรทัด:
- ZITADEL ถ้าคุณต้องการรองรับหลายผู้เช่าและองค์กรแบบ B2B ตั้งแต่แกะกล่อง
- FusionAuth ถ้าคุณต้องการหน้าจอผู้ดูแลระบบที่ขัดเกลามาดีและประวัติการออกเวอร์ชันที่ยาวและคาดเดาได้
- Logto ถ้าคุณต้องการประสบการณ์นักพัฒนาที่เรียบร้อยที่สุดตั้งแต่วันแรก
- Ory Hydra ถ้าคุณสร้างงานในระดับโปรโตคอลและต้องการเอนจิน OAuth 2.0 ไม่ใช่แอปล็อกอินสำเร็จรูป
สรุปคือ ZITADEL เป็นตัวเลือกแรกที่ปลอดภัยที่สุดสำหรับ B2B SaaS ทั่วไป และเนื้อหาที่เหลือของบทความคือการแจกแจงเหตุผลนั้น
ทำไม CIAM จึงเป็นการตัดสินใจคนละเรื่องกับ SSO สำหรับพนักงาน
ถ้า SSO สำหรับทีมภายในล่ม ความเสียหายมักจำกัดวง วิศวกรของคุณอาจเข้า Grafana หรือเครื่องมือภายในอื่นไม่ได้สักชั่วโมง แต่ถ้า CIAM ล่ม ลูกค้าที่จ่ายเงินจะเข้าสู่ระบบผลิตภัณฑ์ไม่ได้เลย นั่นเปลี่ยนคำถามจาก "เครื่องมือยืนยันตัวตนตัวไหนสะดวกกับทีมเรา" ไปเป็น "ระบบยืนยันตัวตนตัวไหนที่เราไว้ใจให้เป็นส่วนหนึ่งของตัวผลิตภัณฑ์ได้"
CIAM ซึ่งเป็นโครงสร้างพื้นฐานด้านตัวตนแบบที่ B2B SaaS ต้องการ ยังต้องอาศัยองค์ประกอบพื้นฐานที่เครื่องมือ SSO สำหรับพนักงานหลายตัวไม่ได้ให้ความสำคัญ ลูกค้าของคุณไม่ใช่ผู้ใช้คนเดียว แต่คือองค์กร (ผู้เช่าหนึ่งราย) ที่มีผู้ใช้ บทบาท แบรนด์ของตัวเอง และอาจมีการเชื่อมต่อ SAML ของตัวเองไปยัง IdP ขององค์กร คุณไม่ได้แค่ยืนยันตัวตนของคน แต่กำลังแยกผู้ใช้ของบริษัทหนึ่งออกจากผู้ใช้ของอีกบริษัทภายในผลิตภัณฑ์เดียวกัน นี่คือรูปแบบ B2B ที่เครื่องมือทั้งสี่ด้านล่างมุ่งเป้าไปในแบบที่ต่างกัน ตอนนี้ Keycloak มี Organizations เป็นแนวคิดหลักในตัวแล้ว การมองว่ามันใช้ได้เฉพาะกับพนักงานภายในจึงล้าสมัยไปแล้ว ผมอธิบายเหตุผลที่ไม่นำมารวมไว้ในส่วนคำถามที่พบบ่อย
สามเหลี่ยมสร้างเอง ซื้อ หรือโฮสต์เอง ก็หน้าตาต่างออกไปในเรื่องนี้ การเขียน OAuth ขึ้นมาเองตั้งแต่ต้นคือความผิดพลาดที่ไม่จำเป็น คุณกำลังส่งมอบผลิตภัณฑ์ SaaS ไม่ใช่ผู้ให้บริการตัวตน การซื้อบริการแบบมีผู้ดูแล (Auth0, Clerk, WorkOS) เป็นทางเลือกที่ถูกต้องเมื่อทีมของคุณไม่มีกำลังด้านปฏิบัติการเลยและมีงบประมาณพอสมควร ผมจะไม่มีวันบอกสตาร์ตอัปสองคนให้โฮสต์ระบบยืนยันตัวตนเองตั้งแต่วันแรก การโฮสต์เองเริ่มสมเหตุสมผลเมื่อราคาต่อ MAU ของ CIAM แบบมีผู้ดูแลแซงต้นทุนโครงสร้างพื้นฐานบวกเวลาวิศวกรที่ต้องใช้ต่อเนื่อง หรือเมื่อคุณต้องการควบคุมการติดตั้งและชั้นข้อมูลโดยตรง ในทีมที่ผมเคยร่วมงาน จุดนั้นมักมาถึงระหว่าง "เรามีผลิตภัณฑ์จริงแล้ว" กับ "เรามีทีมดูแลความสำเร็จของลูกค้าจริงแล้ว"
ถ้าคุณกำลังมองหา SSO สำหรับแอปของคุณเอง ไม่ใช่ของลูกค้า นั่นคือการเปรียบเทียบคนละชุดกับบทความนี้ มาต่อกันที่ตัวเลือกเด่นของเรา
เครื่องมือทั้งสี่ ทีละตัว
ผมเลือกสี่ตัวนี้เพราะมันมีรูปร่างเป็น CIAM มากพอที่จะประเมินในฐานะโครงสร้างพื้นฐานของผลิตภัณฑ์ ไม่ใช่แค่ SSO ภายใน ทั้ง ZITADEL, FusionAuth, Logto และ Ory ล้วนมีเส้นทางโฮสต์เองที่ใช้งานได้จริงและมีแรงส่งมากพอที่จะพิจารณาอย่างจริงจัง ส่วนตัวเลือกที่เป็นแค่ไลบรารี ที่เน้น SSO สำหรับพนักงาน และที่ยังไม่สุกงอม เหมาะจะพูดถึงในส่วนคำถามที่พบบ่อยมากกว่า
ZITADEL
ZITADEL คือแพลตฟอร์มด้านตัวตนที่พัฒนาในสวิตเซอร์แลนด์ เขียนด้วย Go ใช้สถาปัตยกรรมแบบ event-sourced และมี PostgreSQL เป็นแบ็กเอนด์ ณ วันที่ 27 กรกฎาคม 2026 รุ่นล่าสุดบน GitHub คือ the 4.16 series, current as of July 2026 ZITADEL เปลี่ยนจาก Apache 2.0 ไปเป็น AGPL-3.0 ตั้งแต่ v3 เป็นต้นไป สำหรับการใช้งาน SaaS ทั่วไป ผลกระทบจริงมักไม่น่ากลัวอย่างที่ได้ยิน และผมลงรายละเอียดไว้ในส่วนคำถามที่พบบ่อย
สิ่งที่ทำให้ ZITADEL ต่างออกไปสำหรับ B2B SaaS: องค์กรและการรองรับหลายผู้เช่าเป็นองค์ประกอบพื้นฐานระดับหลัก ไม่ใช่ฟีเจอร์ที่คุณต้องประกอบขึ้นจากอ็อบเจกต์ทั่วไป คุณสร้าง Organization ขึ้นมา มันจะมีผู้ใช้ นโยบาย แบรนด์ และการตั้งค่าการเข้าถึงของตัวเอง และคุณมอบโปรเจกต์ให้องค์กรนั้นได้ เพื่อให้ผู้ดูแลของเขาจัดการการกำหนดบทบาทให้ผู้ใช้ของตัวเอง คุณไม่ต้องประดิษฐ์แนวคิด "ผู้เช่า" ทับลงบนผู้ใช้ทั่วไป คุณเริ่มต้นด้วยมันเลย
ประสบการณ์นักพัฒนาเป็นแบบ API-first มีทั้ง REST resource API รุ่น v2 ปัจจุบัน และการเข้าถึงบริการ v1 เดิมผ่าน gRPC และ REST มี SDK ทั้งจากทีมงานและชุมชนครอบคลุมสแตกฝั่งเซิร์ฟเวอร์ที่ใช้กันทั่วไป คอนโซลผู้ดูแลใช้งานได้ดีแต่เรียบง่ายกว่าของ FusionAuth
มุมมองของผม: ถ้าคุณกำลังสร้าง B2B SaaS และรู้ว่าจะมีผู้เช่าหลายราย ผมจะเริ่มที่ ZITADEL ในบรรดาตัวเลือกแบบโฮสต์เอง นี่คือตัวที่ออกแบบรอบโจทย์การล็อกอินแบบ B2B ชัดเจนที่สุด
FusionAuth
FusionAuth เป็นแพลตฟอร์มสัญชาติอเมริกันจาก Inversoft, LLC (บริษัท LLC ในรัฐเดลาแวร์ ดำเนินงานในชื่อ FusionAuth) ที่อยู่ในตลาดนานกว่าอีกสามตัว และมันแสดงออกมาในทางที่ดี หน้าจอผู้ดูแลรู้สึกได้ว่าออกแบบมาดีกว่าตัวอื่นอย่างชัดเจน เอกสารสุกงอม และจังหวะการออกเวอร์ชันสม่ำเสมอมากกว่าจะรีบเร่ง ถ้าคุณเคยรับช่วงต่อการเชื่อมต่อระบบยืนยันตัวตนอายุสี่ปีแล้วแอบขอบคุณวิศวกรคนก่อนที่เลือกตัวเลือกน่าเบื่อ FusionAuth คือ CIAM เวอร์ชันที่คู่ควรกับคำขอบคุณนั้น
เรื่องที่ทำให้คนสะดุดคือสัญญาอนุญาต FusionAuth Community โฮสต์เองได้ฟรี แต่ตัวผลิตภัณฑ์หลักไม่ใช่โอเพนซอร์ส ผลิตภัณฑ์นี้อยู่ภายใต้ สัญญาอนุญาตของ FusionAuth เอง และข้อจำกัดเหล่านั้นสำคัญถ้าคุณวางแผนจะแจกจ่ายต่อ ฝังรวม เปลี่ยนแบรนด์ ขายต่อ หรือโฮสต์ FusionAuth ให้ลูกค้าของคุณเอง รุ่น Community ที่โฮสต์เองครอบคลุมกรณีหลักของ B2B SaaS อยู่แล้ว แพ็กเกจแบบเสียเงินเพิ่มฟีเจอร์ เช่น SAML ที่เริ่มจากฝั่ง IdP, MFA ขั้นสูง และธีมเฉพาะแอปพลิเคชัน ขณะที่ SCIM, Tenant Manager และนโยบาย MFA ระดับแอปพลิเคชันอยู่ในรุ่น Enterprise
ในแง่รูปแบบ B2B: FusionAuth จำลองผู้เช่าและแอปพลิเคชัน แต่การนามธรรมเป็นแบบ "การยืนยันตัวตนแยกคอนเทนเนอร์ต่อผู้เช่า" มากกว่า "องค์กร B2B ในฐานะอ็อบเจกต์ของโดเมน" มันใช้งานได้ (ผมเคยส่งผลิตภัณฑ์บนมันมาแล้ว) แต่การรองรับหลายผู้เช่าให้ความรู้สึกเหมือนกลไกแยกส่วนมากกว่าจะเป็นโมเดล B2B เต็มรูปแบบ SDK ทางการและไลบรารีฝั่งไคลเอนต์มีให้เลือกกว้าง:
- Angular
- React
- Vue
- iOS
- Android
- Go
- Java
- .NET
- PHP
- Python
- Ruby
- TypeScript
ไลบรารีฝั่งเซิร์ฟเวอร์เป็นไคลเอนต์ API แบบบาง ส่วนคอนโซลผู้ดูแลนั้นส่งต่อให้คนฝ่ายปฏิบัติการที่ไม่ใช่วิศวกรได้ง่ายกว่าตัวอื่นพอสมควร
มุมมองของผม: ถ้าทีมของคุณให้ค่ากับความประณีตของหน้าจอและประวัติที่ยาวและคาดเดาได้ มากกว่าองค์ประกอบพื้นฐานที่เป็น B2B แต่กำเนิด ก็เลือก FusionAuth มันคือตัวเลือกที่ "น่าเบื่อ" ที่สุดในที่นี้ และนั่นคือคำชม
Logto
Logto เป็นตัวใหม่ที่สุดในสี่ตัวนี้ พัฒนาโดย Silverhand Inc. และ ใช้สัญญาอนุญาต MPL-2.0 และเป็นตัวที่เห็นได้ชัดที่สุดว่าใส่ใจแดชบอร์ดของตัวเอง การตั้งค่าวันแรกค่อนข้างเร็ว คุณจัดสรรเครื่อง คลิกผ่านตัวช่วยติดตั้ง แล้วก็ได้ผู้ให้บริการ OIDC ที่ใช้งานได้พร้อมหน้าล็อกอินเริ่มต้นที่ดูดีภายในราวสิบห้านาที (ผมจับเวลาไว้ในสัปดาห์ที่รันทั้งสี่ตัวคู่กัน) คู่มือเริ่มต้นอย่างเป็นทางการครอบคลุมเฟรมเวิร์กและสแตกฝั่งเซิร์ฟเวอร์สมัยใหม่ ดังนั้นถ้าสแตกของคุณคือ "Next.js + Postgres + อะไรสักอย่าง" คุณจะรู้สึกคุ้นเคยทันที
คำตอบสำหรับ B2B ของมันเรียกว่า Logto Organizations มันครอบคลุมองค์ประกอบพื้นฐานหลักของ B2B ได้แก่ การเป็นสมาชิกองค์กร บทบาทที่จำกัดขอบเขตในองค์กร การเชิญสมาชิก การจัดสรรแบบทันเวลา และการเชื่อมต่อ SSO ระดับองค์กร โมเดลองค์กรของมันใหม่กว่าของ ZITADEL ผมจึงจะทดสอบโฟลว์ SAML, SCIM หรือการเชื่อมโยงตัวตนที่แปลกไปกับลูกค้าเป้าหมายของคุณก่อนตัดสินใจผูกมัด
ข้อแลกเปลี่ยนคือความสุกงอม: Logto เป็นตัวเลือกที่ใหม่ที่สุดในที่นี้ โรดแมปเดินเร็ว ซึ่งดีมากเวลาฟีเจอร์ที่คุณต้องการมาถึง และน่าอึดอัดเวลามีการเปลี่ยนแปลงที่ทำของเดิมพัง ถ้า B2B SaaS ของคุณอยู่ทางฝั่งที่ง่ายของสเปกตรัมการรองรับหลายผู้เช่า (มีองค์กรไม่กี่ราย และไม่มีข้อกำหนดการเชื่อมโยงตัวตนแปลก ๆ) ประสบการณ์นักพัฒนาของ Logto จะทำให้ส่วนที่เหลือของการตัดสินใจง่ายขึ้น
มุมมองของผม: ถ้าคุณต้องการวันแรกที่เร็วที่สุดและความต้องการด้าน B2B ยังค่อนข้างเรียบง่าย เลือก Logto
Ory Hydra (และสแตก Ory)
Ory Hydra คือเซิร์ฟเวอร์ OAuth 2.0 / OpenID Connect จากระบบนิเวศ Ory ใช้สัญญาอนุญาต Apache-2.0 สแตก Ory เต็มรูปแบบจับคู่ Hydra เข้ากับ Ory Kratos (ตัวตนและการจัดการผู้ใช้ การล็อกอินแบบบริการตัวเอง การสมัคร MFA และการกู้คืนบัญชี), Ory Keto (เซิร์ฟเวอร์การให้สิทธิ์สไตล์ Zanzibar ที่ทำหน้าที่เป็นจุดตัดสินใจเชิงนโยบาย) และ Ory Oathkeeper (พร็อกซีด้านตัวตนและการเข้าถึงที่ยืนยันตัวตน ให้สิทธิ์ และปรับแต่งคำขอ HTTP ขาเข้า) คุณประกอบเฉพาะสิ่งที่ต้องการ ทุกอย่างเขียนด้วย Go และ API สะอาดตา
จุดที่ต้องรู้ (และนี่ไม่ใช่ข้อบกพร่อง สำหรับทีมที่เหมาะสมมันคือข้อดี) คือ Hydra เป็นเอนจิน ไม่ใช่ตัวแอปพลิเคชัน โดยการออกแบบแล้ว Hydra จะเชื่อมต่อกับแอปล็อกอินและให้ความยินยอมที่แยกต่างหาก ซึ่งคุณเป็นคนจัดหาเอง ถ้าคุณอยากได้หน้าจอล็อกอินสำเร็จรูป นี่ไม่ใช่เครื่องมือที่ใช่ แต่ถ้าคุณกำลังสร้างอะไรที่โฟลว์การยืนยันตัวตนเป็นส่วนหนึ่งของผลิตภัณฑ์ (แพลตฟอร์มสำหรับนักพัฒนา พอร์ทัล B2B ที่ทำเอง หรือผลิตภัณฑ์แบบ API-first ที่มีการเริ่มใช้งานเฉพาะทาง) การไม่มี UI ที่ถูกกำหนดมาให้ก็คือสิ่งที่คุณต้องการพอดี
เรื่องราวฝั่ง B2B ของมันเป็นแบบประกอบเอง ไม่ใช่แบบพร้อมใช้ คุณจำลองการรองรับหลายผู้เช่าได้ด้วยการต่อสคีมาของ Kratos และความสัมพันธ์ของ Keto เข้ากับเลเยอร์องค์กรของคุณเอง และมันได้ผล แต่คุณเป็นคนเดินสายเอง ต้นทุนคืองานท่อที่เพิ่มขึ้น ผลตอบแทนคือการควบคุมประสบการณ์ เอกสารของ Ory ครอบคลุมพื้นผิวของโปรโตคอลอย่างลึก แต่โมเดลแบบประกอบเองตั้งสมมติฐานว่าคุณสบายใจที่จะตัดสินใจในระดับโปรโตคอลด้วยตัวเอง ถ้า "audience claim" หรือ "PKCE" ไม่มีความหมายอะไรกับคุณ ให้เริ่มจากอีกสามตัวที่เหลือ
มุมมองของผม: ถ้าคุณกำลังสร้างอะไรในระดับโปรโตคอล (เกตเวย์ยืนยันตัวตน โฟลว์เฉพาะทาง แพลตฟอร์มสำหรับนักพัฒนา) และแอปมาตรฐานรู้สึกอึดอัด Ory คือคำตอบที่ถูกต้อง แต่สำหรับ B2B SaaS ทั่วไปที่อยากให้ล็อกอินใช้งานได้วันนี้ มันไม่ใช่
เปรียบเทียบแบบเห็นภาพรวม
นี่คือสรุปเครื่องมือทั้งสี่ในตารางเดียว มีประโยชน์ตอนอ่านรอบสอง ไม่ใช่ตัวแทนของการอ่านรายละเอียดด้านบน
| เครื่องมือ | สัญญาอนุญาต | โมเดลผู้เช่า | องค์ประกอบพื้นฐาน B2B | SDK | เวอร์ชันมีผู้ดูแล |
|---|---|---|---|---|---|
| ZITADEL | AGPL-3.0 | Organizations เป็นแนวคิดหลัก | แข็งแรง: องค์กร บทบาทที่จำกัดขอบเขต และการตั้งค่าระดับองค์กร | REST v2; gRPC/REST v1 รุ่นเดิม; SDK ทางการและจากชุมชน | มี (ZITADEL Cloud) |
| FusionAuth | สัญญาอนุญาตของ FusionAuth; แพ็กเกจ Community โฮสต์เองได้ฟรี | ผู้เช่า + แอปพลิเคชัน | แยกส่วนได้ดี; เป็นรูปแบบ B2B น้อยกว่า | SDK ฝั่งเว็บ มือถือ และเซิร์ฟเวอร์ครอบคลุมกว้าง | มี (FusionAuth Cloud) |
| Logto | MPL-2.0 | Organizations | บทบาทในองค์กร คำเชิญ การจัดสรรแบบ JIT และ SSO ระดับองค์กร | SDK ฝั่งเว็บ มือถือ และเซิร์ฟเวอร์แบบสมัยใหม่ | มี (Logto Cloud) |
| Ory Hydra | Apache 2.0 | ประกอบ Hydra + Kratos + Keto | สร้างเองจากองค์ประกอบพื้นฐาน | ไคลเอนต์ที่สร้างอัตโนมัติ; ระดับต่ำกว่า | มี (Ory Network) |
ควรเริ่มจากตัวไหน
สี่สถานการณ์สั้น ๆ ที่ครอบคลุมทีมส่วนใหญ่ที่ผมมักคุยเรื่องนี้ด้วย
คุณกำลังสร้าง B2B SaaS และรู้ว่าจะมีผู้เช่าหลายราย เริ่มที่ ZITADEL องค์ประกอบพื้นฐานด้านการรองรับหลายผู้เช่าและองค์กรถูกออกแบบมาเพื่อสิ่งนี้พอดี พื้นผิว API ครบถ้วน และคุณจะเสียเวลาประดิษฐ์โมเดลผู้เช่าน้อยกว่าอีกสามตัว การเปลี่ยนไปใช้ AGPL ควรได้รับการตรวจสอบด้านสัญญาอนุญาต แต่การติดตั้งที่ไม่ได้ดัดแปลงและเชื่อมต่อแยกต่างหากมักเป็นกรณีใช้งาน SaaS ที่ตรงไปตรงมา
คุณต้องการหน้าจอผู้ดูแลที่ขัดเกลามาดีและแพลตฟอร์มที่นิ่งและคาดเดาได้ FusionAuth แพ็กเกจ Community ครอบคลุมความต้องการหลักของหลายทีม แต่ควรกันเวลาไว้อ่านสัญญาอนุญาตและตารางฟีเจอร์ให้ละเอียด ฟีเจอร์อย่าง SAML ที่เริ่มจากฝั่ง IdP, MFA ขั้นสูง และธีมเฉพาะแอปพลิเคชัน ต้องใช้แพ็กเกจแบบเสียเงิน ขณะที่ SCIM, Tenant Manager และนโยบาย MFA ระดับแอปพลิเคชันอยู่ในรุ่น Enterprise
ความต้องการด้าน B2B ของคุณตอนนี้ยังเรียบง่าย และคุณอยากได้วันแรกที่เร็วที่สุด Logto ประสบการณ์นักพัฒนาวันแรกของมันเร็วที่สุดในการทดสอบเทียบเคียงของผม ยอมรับว่าคุณกำลังเดิมพันกับระบบนิเวศที่อายุน้อยกว่า และกลับมาทบทวนตัวเลือกนี้ถ้าความต้องการของคุณโตไปถึงกรณีขอบด้านการเชื่อมโยงตัวตนที่คุณยังไม่ได้ทดสอบ
คุณกำลังสร้างอะไรที่โฟลว์การยืนยันตัวตนเป็นส่วนหนึ่งของประสบการณ์ผลิตภัณฑ์ Ory Hydra (บวก Kratos และบวก Keto ถ้าคุณต้องการระบบสิทธิ์) คุณจะเขียนโค้ดมากขึ้น คุณจะควบคุมได้มากขึ้น ถ้าการแลกเปลี่ยนนี้ยังไม่ชัดสำหรับคุณ คุณก็ไม่ใช่กลุ่มเป้าหมายของ Ory ไปเลือกอีกสามตัวที่เหลือดีกว่า
ถ้ามีสองข้อในคำอธิบายเหล่านี้ที่ตรงกับคุณ ให้เลือก ZITADEL เป็นค่าเริ่มต้น มันเข้ากันได้กว้างที่สุด และเป็นตัวที่ผมจะยื่นให้ทีมผู้ก่อตั้งขนาดเล็กโดยไม่ต้องถามอะไรเพิ่มมากนัก
การโฮสต์เองมีต้นทุนอะไรบ้าง (ในเชิงปฏิบัติการ)
ต่อไปนี้คือส่วนที่ไม่โรแมนติกของบทความ
วินัยการสำรองข้อมูล PostgreSQL ของคุณกลายเป็นสิ่งที่ธุรกิจต้องพึ่งพาแล้ว ในการติดตั้งเหล่านี้ สถานะตัวตนที่คุณต้องปกป้องอาจรวมถึงระเบียนผู้ใช้ ข้อมูลรับรองที่ผ่านการแฮช ความลับของ MFA ข้อมูลรับรองไคลเอนต์ OAuth และข้อมูลเซสชัน ถ้าสูญเสียสถานะนั้นไป ลูกค้าของคุณอาจล็อกอินไม่ได้เลย ตั้งค่าการสำรองข้อมูลอัตโนมัติก่อนที่ผู้ใช้จริงคนแรกจะสมัคร ทดสอบการกู้คืน และเอาสถานะสุขภาพของการสำรองไปไว้ในช่องแจ้งเตือนเดียวกับ uptime ของแอปพลิเคชัน
จังหวะการออกเวอร์ชันเปลี่ยนไปตามเวลา ZITADEL v4.16.1 ออกเมื่อ 17 กรกฎาคม 2026 หลังจากมีหลายรุ่นในเดือนมิถุนายน ขณะที่ทุกโปรเจกต์ในที่นี้ต่างมีจังหวะและนโยบายความเข้ากันได้ของตัวเอง ให้มองจังหวะนั้นเป็นเรื่องของการบำรุงรักษา ไม่ใช่ทางลัดในการตัดสินคุณภาพ อ่านบันทึกการเปลี่ยนแปลงก่อนสั่ง docker compose pull และวางกำหนดช่วงเวลาแพตช์ประจำ การข้ามการอัปเดตผู้ให้บริการตัวตนไปหลายเดือนอาจทำให้คุณตามหลังการแก้ไขด้านความปลอดภัยและความเข้ากันได้ ตอนที่มีการตรวจสอบจริงครั้งแรก
เรื่องจืด ๆ ที่มักย่องมาเล่นงานเสมอ: การต่ออายุใบรับรอง TLS (ใช้ reverse proxy คู่กับ Let's Encrypt ทำการต่ออายุอัตโนมัติ และตั้งแจ้งเตือนเมื่อพลาด), การตั้งค่าเมลขาออกสำหรับอีเมลยืนยันตัวตนและรีเซ็ตรหัสผ่าน (SES, SendGrid, Postmark: เลือกสักเจ้าแล้วตั้ง SPF/DKIM/DMARC ให้ถูกต้อง ไม่อย่างนั้นอีเมลรีเซ็ตรหัสผ่านจะไปลงถังสแปม), การหมุนเวียนข้อมูลรับรองไคลเอนต์ OAuth เมื่อมีวิศวกรลาออก และการจำกัดอัตราคำขอที่ปลายทางล็อกอิน เพื่อไม่ให้การโจมตีแบบ credential stuffing ตรึง CPU ของคุณ
เคล็ดลับ: ถ้าคุณใช้ Postgres แบบมีผู้ดูแล อย่าสันนิษฐานว่าผู้ใช้ฐานข้อมูลตอนรันไทม์จะสร้างสคีมาได้ด้วย ให้สร้างฐานข้อมูลและผู้ใช้ไว้ล่วงหน้า มอบสิทธิ์ความเป็นเจ้าของหรือสิทธิ์ติดตั้งที่จำเป็น แล้วรันการตั้งค่าครั้งแรกด้วยข้อมูลรับรองที่เครื่องมือแต่ละตัวคาดหวัง ไม่อย่างนั้นการรันครั้งแรกอาจล้มด้วยข้อความสิทธิ์ฐานข้อมูลที่คลุมเครือ และคุณจะเสียเวลาเป็นชั่วโมงไล่ผิดทาง
สิ่งที่เส้นทางโฮสต์เองช่วยประหยัดเป็นตัวเงิน มันเก็บคืนในรูปของความเป็นเจ้าของ หลังติดตั้งเสร็จ ให้กันเวลาวิศวกรไว้สักไม่กี่ชั่วโมงต่อเดือนเพื่อดูแลชั้นตัวตนให้แข็งแรง ทีมที่จัดสรรเวลาไว้ศูนย์มักมาเจอต้นทุนนี้ทีหลัง ตอนระบบล่ม ตอนเจอกรณีขอบแปลก ๆ ของ SAML หรือตอนตรวจสอบความปลอดภัยครั้งแรก
ควรติดตั้งไว้ที่ไหน
VPS Linux ที่รัน Docker Compose อาจเป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับการทดลองและงานขนาดย่อม แต่การกำหนดขนาดสำหรับใช้งานจริงและความพร้อมใช้งานสูงขึ้นอยู่กับปริมาณทราฟฟิก ข้อกำหนดด้านความปลอดภัย และระดับที่คุณยอมรับการหยุดทำงานได้ ตัวเลือกการติดตั้งที่พบบ่อยเข้ากันได้ดังนี้:
- โฮสติ้งแบบแชร์ รันไม่ได้สักตัว พวกมันต้องการพื้นที่จัดเก็บถาวร พอร์ตเฉพาะ สิทธิ์ root สำหรับรันไทม์คอนเทนเนอร์ และแบ็กเอนด์ฐานข้อมูลจริง ๆ PostgreSQL เป็นเส้นทางเริ่มต้นของรายการส่วนใหญ่นี้ แต่ก็ไม่ใช่ฐานข้อมูลเดียวที่ทุกเครื่องมือรองรับตามตัวอักษร
- Kubernetes รันได้ทั้งสี่ตัว แต่เส้นทางที่ผู้พัฒนาสนับสนุนเองนั้นไม่เท่ากัน ZITADEL, FusionAuth, และ Ory เผยแพร่ Helm chart อย่างเป็นทางการ ขณะที่ เอกสารการโฮสต์เองของ Logto เน้นการติดตั้งด้วย Docker และเครื่องเสมือน สำหรับ B2B SaaS ขนาดเล็กที่ยังไม่ถึงจุดที่ Kubernetes คุ้มค่าในด้านอื่น ๆ นี่มักเป็นการออกแบบเกินจำเป็น ให้หยิบมาใช้เมื่อโครงสร้างพื้นฐานส่วนที่เหลือของคุณอยู่บนนั้นอยู่แล้ว
- เซิร์ฟเวอร์จริง (bare metal) ก็ใช้ได้ถ้าคุณอยู่บนนั้นอยู่แล้ว ทีม B2B SaaS ส่วนใหญ่ไม่ได้อยู่
สำหรับการทดลองขนาดเล็กแบบโหนดเดียว ผมจะเริ่มที่ RAM 4 GB, 2 vCPU และพื้นที่ NVMe 60 GB แล้วค่อยทดสอบโหลดกับโฟลว์ล็อกอินจริง นั่นคือฐานสำหรับวางแผน ไม่ใช่ขั้นต่ำสำหรับใช้งานจริงแบบสากล ตัวแอปพลิเคชันค่อนข้างเบา แต่ PostgreSQL ต้องใช้หน่วยความจำ และการแฮชรหัสผ่านต้องมี CPU เหลือ คำแนะนำสำหรับใช้งานจริงของ ZITADEL แนะนำให้เตรียม CPU ไว้สี่คอร์สำหรับช่วงที่การแฮชรหัสผ่านพุ่งสูง
เมื่อผลิตภัณฑ์เป็นจริงและทราฟฟิกมาต่อเนื่อง ให้ปรับขนาดจากค่าที่วัดได้ พื้นที่จัดเก็บที่เร็วช่วยเรื่องความหน่วงของ PostgreSQL ขณะที่ CPU ที่เหลือสำคัญตอนแฮชรหัสผ่านพร้อมกันหลายรายการ ให้เฝ้าดูหน่วยความจำ I/O ของฐานข้อมูล ความหน่วงของการล็อกอิน และความอิ่มตัวของ CPU แทนที่จะเหมาว่าทรัพยากรใดสำคัญที่สุด
การรัน CIAM ในระบบจริงหมายความว่าความพร้อมใช้งานของมันกลายเป็นปัญหาของคุณแล้ว เราใช้เครื่อง Cloudzy Linux VPS สำหรับงานลักษณะนี้ พร้อมพื้นที่จัดเก็บ NVMe และ SLA ความพร้อมใช้งาน 99.95% บนแพลตฟอร์มพื้นฐาน นอกจากนี้ Cloudzy ยังมี VPS สำหรับ ZITADEL แบบคลิกเดียว ถ้าคุณอยากข้ามสคริปต์จัดเตรียมระบบตอนเริ่ม ส่วนอีกสามตัวมีอิมเมจคอนเทนเนอร์อย่างเป็นทางการสำหรับติดตั้งด้วย Docker หากอยากได้มุมมองระดับผู้บริหารว่าการควบคุมการเข้าถึงเข้ากับภาพรวมความมั่นคงปลอดภัยอย่างไร คู่มือแนวปฏิบัติที่ดีด้าน IAM อธิบายเรื่องนี้จากมุมของนโยบายไว้แล้ว
พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC
ดูแพ็กเกจ Linuxคำถามที่พบบ่อย
สัญญาอนุญาต AGPL ของ ZITADEL กระทบ SaaS ของผมไหม
โดยทั่วไปไม่ ถ้าเป็นการติดตั้งที่ไม่ได้ดัดแปลงและเชื่อมต่อแยกต่างหาก แต่นี่ไม่ใช่คำแนะนำทางกฎหมาย ภาระผูกพันของ AGPL ที่ ZITADEL มีนั้นใช้กับตัว ZITADEL เอง ถ้าคุณดัดแปลง ZITADEL แล้วให้บริการเวอร์ชันที่ดัดแปลงนั้นเป็นบริการผ่านเครือข่าย สัญญาอนุญาตอาจกำหนดให้คุณเปิดเผยซอร์สโค้ดที่เกี่ยวข้องภายใต้ AGPL จุดยืนที่ ZITADEL เผยแพร่ไว้คือ การใช้อินสแตนซ์ที่ไม่ได้ดัดแปลงเป็นบริการตัวตนของ SaaS ของคุณเฉย ๆ นั้น ตัวมันเองไม่ได้บังคับให้คุณต้องเผยแพร่แอปพลิเคชันแยกของคุณภายใต้ AGPL อ่าน ประกาศเรื่องสัญญาอนุญาตของ ZITADEL และขอคำแนะนำทางกฎหมายถ้าคุณดัดแปลง แจกจ่ายต่อ ฝังรวม หรือให้บริการซอฟต์แวร์นี้แก่บุคคลภายนอก ทั้งนี้มีสัญญาอนุญาตเชิงพาณิชย์ให้เลือกด้วย
ทำไม Keycloak หรือ Authentik ถึงไม่อยู่ในรายการนี้
Keycloak และ Authentik เป็นเครื่องมือด้านตัวตนแบบโฮสต์เองที่ยอดเยี่ยม (ผมก็ใช้อยู่) แต่การตัด Keycloak ออกเพราะไม่มีองค์กรแบบ B2B นั้นตอนนี้ผิดไปแล้ว เพราะ Keycloak รุ่นปัจจุบันมีทั้ง Organizations กลุ่มขององค์กร และการมอบอำนาจการดูแลระบบ ผมไม่ได้ใส่ไว้เพราะบทความนี้เน้นสี่ตัวเลือกที่มีเส้นทางตรงกว่าสำหรับ B2B SaaS ทีมเล็ก ส่วน Keycloak สมควรได้รับการประเมินของตัวเองเมื่อการดูแล JVM ความลึกของระบบนิเวศ และความยืดหยุ่นระดับ realm เป็นเรื่องสำคัญ ส่วน Authentik ยังคงเหมาะกับ SSO สำหรับพนักงานและแอปภายในมากกว่าการจำลองผู้เช่าที่ผูกกับตัวผลิตภัณฑ์
การโฮสต์เองถูกกว่า Auth0 ไหม
ถ้า MAU ยังต่ำ มักจะไม่ ชั่วโมงวิศวกรของคุณแพงกว่าบิล Auth0 ในระดับสตาร์ตอัประยะแรก การโฮสต์เองชนะเชิงเศรษฐศาสตร์ที่ระดับซึ่งราคาต่อ MAU ของ CIAM แบบมีผู้ดูแลแซงต้นทุนรวมของ VPS เครื่องเล็กบวกชั่วโมงวิศวกรไม่กี่ชั่วโมงต่อเดือนที่คุณต้องใช้ จุดคุ้มทุนที่แน่นอนขึ้นอยู่กับต้นทุนต่อชั่วโมงของทีมคุณ เส้นโค้งการเติบโตของ MAU และผลิตภัณฑ์ของคุณต้องใช้ฟีเจอร์ระดับองค์กรที่ดันคุณขึ้นไปแพ็กเกจราคาสูงของ Auth0 หรือไม่ ให้มองว่าเงินที่ประหยัดได้นั้นมีจริง แต่ไม่ได้มาทันที
ขนาด VPS ขั้นต่ำสำหรับ CIAM ที่ใช้งานจริงคือเท่าไร
สำหรับการทดลองขนาดเล็กแบบโหนดเดียว RAM 4 GB, 2 vCPU และพื้นที่ NVMe เป็นจุดเริ่มต้นที่สมเหตุสมผล ไม่ใช่การรับประกันสำหรับใช้งานจริง ให้กำหนดขนาดจากขนาดฐานข้อมูล ปริมาณการล็อกอินพร้อมกัน ต้นทุนการแฮชรหัสผ่าน และเป้าหมายความพร้อมใช้งานของคุณ คำแนะนำสำหรับใช้งานจริงของ ZITADEL เองแนะนำให้มี CPU สี่คอร์พร้อมใช้สำหรับช่วงแฮชพุ่งสูง ส่วนเครื่องมืออื่นและรูปแบบทราฟฟิกอื่นต้องทดสอบโหลดของตัวเอง
ภายหลังผมย้ายจาก CIAM แบบมีผู้ดูแลไปเป็นโฮสต์เองได้ไหม
ได้ แต่ให้วางแผนเป็นโครงการจริงจัง การรีเซ็ตรหัสผ่านไม่ใช่สิ่งที่เลี่ยงไม่ได้ ความสามารถในการส่งออกและรูปแบบแฮชที่รองรับนั้นต่างกันไป และบางปลายทางรองรับ การย้ายผู้ใช้แบบยกชุดหรือแบบทันเวลา ขณะที่บางแห่งบังคับให้ต้องรีเซ็ต ปัจจัย MFA ไคลเอนต์ OAuth เซสชันที่ยังใช้งานอยู่ สถานะการยืนยันอีเมล และการแมปผู้เช่าหรือบทบาท ล้วนต้องจัดการแยกต่างหาก ถ้าคุณเริ่มสงสัยแล้วว่าภายหลังจะโฮสต์เอง ให้บันทึกข้อจำกัดด้านการส่งออกและการย้ายข้อมูลเหล่านี้ไว้ก่อนเลือกผู้ให้บริการแบบมีผู้ดูแล
