คุณมีคอนเทนเนอร์ Docker แปดตัวรันอยู่บน VPS ทั้ง Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, หน้าแสดงสถานะ และแอปภายในอีกหนึ่งตัวที่คุณเขียนเอง แต่ละตัวมีล็อกอินของตัวเอง ทุกเช้าคุณคัดลอกรหัสผ่านจากตัวจัดการรหัสผ่านมาวาง แล้วก็เริ่มสงสัยว่า single sign-on คุ้มกับต้นทุนการดูแลระบบหรือไม่
ส่วนใหญ่แล้วคุ้ม คำถามคือควรรันผู้ให้บริการข้อมูลประจำตัวตัวไหน
Keycloak คือค่าเริ่มต้นที่คุ้นเคย แต่ตัวเลือกที่เหมาะกว่าขึ้นอยู่กับหน้าตาสแต็กของคุณ จำนวนผู้ใช้ที่คุณดูแล และคุณกำลังเชื่อมต่อซอฟต์แวร์ที่รันอยู่แล้ว หรือกำลังสร้างระบบยืนยันตัวตนลงในแอปพลิเคชันของคุณเอง
การเปรียบเทียบ SSO แบบโฮสต์เองนี้มอง Authentik, ZITADEL, Keycloak และ Authelia ผ่านการตัดสินใจที่สำคัญหลังจากติดตั้งใช้งานจริง ได้แก่ การรองรับโปรโตคอล การจัดการผู้ใช้ เวิร์กโฟลว์ของนักพัฒนา ความต้องการทรัพยากร และสิ่งที่เกิดขึ้นเมื่อผู้ให้บริการข้อมูลประจำตัวของคุณล่ม
ทำไม SSO แบบโฮสต์เองจึงสำคัญ
เมื่อแอปพลิเคชันหลายตัวพึ่งพาคนกลุ่มเดียวกันและกลุ่มเดียวกัน การล็อกอินแยกกันก็ไม่สะดวกอีกต่อไป ผู้ให้บริการข้อมูลประจำตัวแบบโฮสต์เองให้คุณจัดการบัญชี MFA สมาชิกกลุ่ม และนโยบายการเข้าถึงได้ในที่เดียว แทนที่จะต้องตั้งค่าเหล่านั้นแยกกันในทุกแอปพลิเคชัน
ข้อแลกเปลี่ยนก็สำคัญไม่แพ้กัน IdP จะกลายเป็นโครงสร้างพื้นฐานที่แอปพลิเคชันอื่นพึ่งพา การล็อกอินใหม่และการรีเฟรชโทเค็นอาจล้มเหลวเมื่อมันใช้งานไม่ได้ ดังนั้นการสำรองข้อมูล การเข้าถึงเพื่อกู้คืน การอัปเกรด และอัปไทม์จึงสำคัญกว่าแอปโฮสต์เองทั่วไปมาก
TL;DR (สรุปย่อ)
เลือก Authentik ถ้าคุณต้องการตัวเลือกเริ่มต้นที่ดีที่สุด
สำหรับ homelab สแต็กเครื่องมือภายใน หรือทีมเล็กที่เชื่อมต่อแอปพลิเคชันที่มีอยู่ผ่าน OIDC หรือ SAML นั้น Authentik คือค่าเริ่มต้นที่แข็งแกร่งที่สุด เวิร์กโฟลว์การดูแลระบบเข้าถึงได้ง่ายกว่าของ Keycloak รองรับวิธีเชื่อมต่อหลายแบบ และการตั้งค่า Docker Compose อย่างเป็นทางการเริ่มต้นที่ CPU 2 คอร์และ RAM 2 GB
เลือก ZITADEL ถ้าคุณกำลังสร้างแอป
เลือก ZITADEL เมื่อการยืนยันตัวตนเป็นส่วนหนึ่งของผลิตภัณฑ์ที่คุณกำลังสร้าง โมเดลองค์กร API ระบบหลายผู้เช่า OIDC, SAML, passkey, MFA และการรองรับผู้ให้บริการข้อมูลประจำตัวแบบ LDAP เหมาะกับทีมแอปพลิเคชัน SaaS และ B2B มากกว่า homelab ทั่วไป
เลือก Keycloak ถ้าคุณต้องการฟีเจอร์ข้อมูลประจำตัวระดับองค์กร
เลือก Keycloak เมื่อคุณต้องการการรวมกับ LDAP หรือ Active Directory ที่ลึกกว่า มี realm หลายตัว นโยบายการอนุญาตแบบละเอียด หรือสภาพแวดล้อมที่สร้างขึ้นรอบ Keycloak อยู่แล้ว เอกสารแนะนำขีดจำกัดหน่วยความจำ 2 GB สำหรับคอนเทนเนอร์ Keycloak ขนาดเล็กที่พร้อมใช้งานจริง ส่วน VPS แบบรวมทุกอย่างที่รัน PostgreSQL ด้วยต้องเผื่อเพิ่ม
ทางเลือกอื่น: เลือก Authelia ถ้าคุณต้องการแค่กำแพงล็อกอินเป็นหลัก
เลือก Authelia เมื่อปัญหาหลักของคุณคือการปกป้องแอปพลิเคชันที่ชั้น reverse proxy มากกว่าการรันแพลตฟอร์มข้อมูลประจำตัวเต็มรูปแบบ มันทำหน้าที่เป็นผู้ให้บริการ OpenID Connect ได้ด้วย แต่การยืนยันตัวตนที่ reverse proxy ยังคงเป็นจุดศูนย์ถ่วงของมัน
สิ่งที่ควรตรวจสอบก่อนเลือกเครื่องมือ SSO
ก่อนเปรียบเทียบฟีเจอร์ ให้จับคู่แต่ละเครื่องมือกับแอปพลิเคชัน โปรโตคอล และแหล่งข้อมูลประจำตัวที่คุณต้องรองรับอยู่แล้ว
มีแอปกี่ตัวที่ต้องใช้ SSO?
เริ่มจากแอปพลิเคชัน ไม่ใช่ผู้ให้บริการข้อมูลประจำตัว สแต็กที่มีแอปพลิเคชันหกตัวซึ่งรองรับ OIDC หรือ SAML อยู่แล้ว เป็นคนละปัญหากับสแต็กของเครื่องมือภายในเก่าๆ ที่ไม่รู้จักโปรโตคอลทั้งสองเลย กรณีแรกชี้ไปที่ IdP เต็มรูปแบบ กรณีที่สองอาจต้องการการยืนยันตัวตนที่ชั้น reverse proxy
แอปของคุณรองรับ OIDC หรือ SAML ไหม?
OIDC คือตัวเลือกทั่วไปสำหรับเว็บแอปพลิเคชันสมัยใหม่ SAML ยังคงสำคัญในซอฟต์แวร์องค์กรและการเชื่อมต่อรุ่นเก่า LDAP อาจสำคัญเมื่อแอปพลิเคชันคาดหวังไดเรกทอรีมากกว่าโฟลว์ SSO บนเว็บ ตรวจสอบว่าแต่ละแอปพลิเคชันรับอะไรได้จริงก่อนเลือก IdP ที่จะมาอยู่ตรงกลาง
คุณกำลังจัดการผู้ใช้ หรือกำลังสร้างระบบล็อกอินลงในแอป?
ถ้างานส่วนใหญ่ของคุณจะเกิดขึ้นในหน้าจัดการระบบขณะเชื่อมต่อแอปพลิเคชันที่มีอยู่ Authentik คือจุดเริ่มต้นตามธรรมชาติ ถ้าการยืนยันตัวตนเป็นส่วนหนึ่งของผลิตภัณฑ์ที่คุณกำลังสร้าง และคุณคาดว่าจะสร้างองค์กร ผู้ใช้ และสิทธิ์ผ่านโค้ด ZITADEL ใกล้เคียงกับเวิร์กโฟลว์นั้นมากกว่ามาก
คุณต้องการ LDAP, Active Directory หรือนโยบายขั้นสูงไหม?
Authentik, ZITADEL และ Keycloak ต่างเชื่อมต่อกับแหล่งข้อมูลประจำตัวที่ใช้ LDAP ได้ในรูปแบบใดรูปแบบหนึ่ง ดังนั้น LDAP เพียงอย่างเดียวจึงไม่ใช่ตัวตัดสินอีกต่อไป Keycloak จะน่าสนใจขึ้นเมื่อการรวมไดเรกทอรีมาพร้อมกับ realm หลายตัว mapper แบบละเอียด ข้อกำหนดการซิงก์ หรือนโยบายการอนุญาตระดับทรัพยากร
Authentik vs ZITADEL vs Keycloak vs Authelia
เครื่องมือทั้งสี่ทับซ้อนกันในเรื่อง SSO แต่เข้าหาเรื่องข้อมูลประจำตัวจากคนละทิศทาง ได้แก่ การเชื่อมต่อแอปพลิเคชัน ข้อมูลประจำตัวของผลิตภัณฑ์ IAM ระดับองค์กร และการเข้าถึงผ่าน reverse proxy
Authentik
Authentik รันการติดตั้งหลักในรูปแบบเซิร์ฟเวอร์ worker และฐานข้อมูล PostgreSQL Redis ไม่ได้เป็นส่วนหนึ่งของสแต็กอีกต่อไป Authentik ถอดการพึ่งพานี้ออกทั้งหมดในรุ่น 2025.10 เอกสาร Docker Compose ฉบับปัจจุบันกำหนดให้โฮสต์มี CPU อย่างน้อย 2 คอร์และ RAM 2 GB
ลักษณะเด่นคือหน้าจัดการระบบ เอนจินโฟลว์ของ Authentik การจัดเตรียมแอปพลิเคชัน และนโยบายตามกลุ่มเข้าถึงได้ง่ายกว่าโมเดลการตั้งค่าที่กว้างกว่าของ Keycloak ถ้าคุณเคยตั้งค่าแอปพลิเคชัน OIDC ใน Keycloak แล้วเสียเวลาหาว่าทำไม claim ในโทเค็นถึงหายไป คุณจะสังเกตความต่างได้เร็ว
รองรับ SAML, OAuth2/OIDC, LDAP และ RADIUS เป็นค่าเริ่มต้นที่เหมาะสำหรับ homelab หรือทีมวิศวกรรมขนาดเล็กที่รันสแต็กแอปแบบโฮสต์เอง
ZITADEL
ZITADEL เขียนด้วย Go เป็นหลัก ใช้สัญญาอนุญาต AGPL-3.0 และอยู่ในสายรุ่น v4.x การติดตั้งประกอบด้วย API ที่เขียนด้วย Go หน้าล็อกอินที่สร้างด้วย Next.js และ PostgreSQL โดยข้อกำหนดปัจจุบันรองรับ PostgreSQL 14 ถึง 18 เอกสาร Docker Compose อย่างเป็นทางการกำหนดให้โฮสต์มี RAM อย่างน้อย 2 GB
ลักษณะเด่นคือ API ZITADEL เปิดพื้นผิวข้อมูลประจำตัวครบชุดผ่าน gRPC และ REST และสร้างบนโมเดลหลายผู้เช่าตั้งแต่ต้น ถ้าคุณกำลังสร้างผลิตภัณฑ์ SaaS และต้องการให้ชั้นล็อกอินเขียนโปรแกรมได้ ทำงานอัตโนมัติได้ และรองรับหลายผู้เช่าโดยค่าเริ่มต้น ZITADEL ใกล้เคียงกับสิ่งที่คุณต้องการมากกว่าตัวเลือกอื่น
รองรับ OIDC, SAML, passkey, MFA, ผู้ให้บริการข้อมูลประจำตัวแบบ LDAP และอินเทอร์เฟซ SCIM v2 ที่ปัจจุบันติดป้าย Preview โมเดลองค์กรและเวิร์กโฟลว์ที่เน้น API ก่อนทำให้มันเหมาะกับทีมผลิตภัณฑ์มากกว่า homelab ธรรมดา
Keycloak
Keycloak คือแพลตฟอร์มจัดการข้อมูลประจำตัวและการเข้าถึงที่เขียนด้วย Java และรันบน Quarkus มันมีพื้นที่การตั้งค่ากว้างกว่าตัวเลือกอื่นในบทความนี้ โดยเฉพาะเมื่อ Realms, Clients, Roles, การรวมผู้ใช้ และ Authorization Services เข้ามาเกี่ยวข้อง
เอกสารคอนเทนเนอร์อย่างเป็นทางการแนะนำขีดจำกัดหน่วยความจำ 2 GB สำหรับการติดตั้งขนาดเล็กที่พร้อมใช้งานจริง ตัวเลขนั้นครอบคลุมเฉพาะคอนเทนเนอร์ Keycloak เอง ถ้า PostgreSQL ใช้ VPS เดียวกัน ให้เผื่อทรัพยากรโฮสต์เพิ่ม
เหตุผลที่ควรยอมรับความซับซ้อนนั้นชัดเจน Keycloak รวมไดเรกทอรี LDAP และ Active Directory ได้ บันทึกเหตุการณ์ของผู้ใช้และผู้ดูแลระบบได้ และบังคับใช้การอนุญาตแบบละเอียดด้วยนโยบายแบบ RBAC, ABAC, ตามผู้ใช้ ตามบริบท และแบบอื่นๆ ได้ ถ้าคุณต้องการการควบคุมเหล่านั้น การตั้งค่าที่เพิ่มขึ้นก็มีเหตุผลรองรับ
Authelia
Authelia เล็กที่สุดในสี่ตัว ใช้สัญญาอนุญาต Apache 2.0 เป็นไบนารี Go ตัวเดียว ปัจจุบันอยู่ที่รุ่น v4.39.x สถาปัตยกรรมต่างจากอีกสามตัว Authelia อยู่หน้า reverse proxy (nginx, Traefik, Caddy, HAProxy) และตัดสินว่าจะให้คำขอผ่านไปถึงแบ็กเอนด์หรือไม่
Authelia ยังมีผู้ให้บริการ OpenID Connect ในตัวด้วย เอกสารของมันยังอธิบายการใช้งาน OIDC ว่าเป็นเบต้าแบบเปิด แต่ตัวผู้ให้บริการได้รับการรับรอง OpenID สำหรับโปรไฟล์ Basic OP, Implicit OP, Hybrid OP, Form Post OP และ Config OP ชุดฟีเจอร์ OIDC ของมันแคบกว่าที่ Authentik หรือ Keycloak มีให้สำหรับการจัดการข้อมูลประจำตัว ซึ่งเป็นเหตุผลที่ Authelia ยังเหมาะที่สุดเมื่อการยืนยันตัวตนที่ reverse proxy คืองานหลัก
เราจะกลับมาพูดถึง Authelia ในหัวข้อของมันเอง สรุปสั้นๆ คือ จุดศูนย์ถ่วงของ Authelia คือการคัดกรองที่ reverse proxy ไม่ใช่การจัดการข้อมูลประจำตัวเต็มรูปแบบ
เปรียบเทียบฟีเจอร์
ตารางด้านล่างจำกัดการเปรียบเทียบไว้ที่ความแตกต่างซึ่งส่งผลต่อการติดตั้งและการดูแลระบบประจำวัน
| ฟีเจอร์ | Authentik | ZITADEL | Keycloak | Authelia |
|---|---|---|---|---|
| โปรโตคอลที่รองรับ | OAuth2/OIDC, SAML, LDAP, RADIUS, การยืนยันตัวตนผ่านพร็อกซี | OAuth2/OIDC, SAML, ผู้ให้บริการข้อมูลประจำตัวแบบ LDAP, SCIM v2 Preview | OAuth2/OIDC, SAML, การรวม LDAP และ Active Directory | ผู้ให้บริการ OIDC บวกการยืนยันตัวตนที่ reverse proxy |
| การจัดการผู้ใช้และกลุ่ม | ผู้ใช้ กลุ่ม นโยบาย โฟลว์ การผูกแอปพลิเคชัน | ผู้ใช้ องค์กร โปรเจกต์ บทบาท สิทธิ์ที่มอบ | ผู้ใช้ กลุ่ม realm บทบาทไคลเอนต์ บทบาท realm การรวม | การจัดการผู้ใช้แบบเบา มักใช้ไฟล์หรือ LDAP เป็นฐาน |
| ประสบการณ์สำหรับนักพัฒนา | มี API แต่จุดแข็งหลักคือหน้าจัดการระบบ | เน้น API ก่อน โมเดลองค์กรและหลายผู้เช่าแข็งแรง | REST API ที่สมบูรณ์ แต่มีโมเดล IAM ขนาดใหญ่กว่าให้ต้องเรียนรู้ | ขับเคลื่อนด้วยการตั้งค่าเป็นหลัก |
| ฟีเจอร์ระดับองค์กร | นโยบาย การรวม outpost การควบคุมการเข้าถึงแอปพลิเคชัน | องค์กร โปรเจกต์ passkey การรวม SCIM v2 Preview | การรวมเชิงลึก realm หลายตัว เหตุการณ์ Authorization Services | กฎควบคุมการเข้าถึงและการผสานกับ reverse proxy ที่แน่นหนา |
| ความง่ายในการติดตั้ง | จุดเริ่มต้นที่ง่ายกว่าสำหรับสแต็กแอปพลิเคชันโฮสต์เองส่วนใหญ่ | ดีที่สุดเมื่อทีมคิดในแบบ API และข้อมูลประจำตัวของผลิตภัณฑ์ | แนวคิดและการตั้งค่ามากกว่า แต่ควบคุมได้ลึกกว่า | ง่ายที่สุดเมื่องานหลักคือการยืนยันตัวตนที่ reverse proxy |
| แนวทางด้านทรัพยากร | ขั้นต่ำ Compose อย่างเป็นทางการ: CPU 2 คอร์และ RAM 2 GB | ขั้นต่ำโฮสต์ Compose อย่างเป็นทางการ: RAM 2 GB | หน่วยความจำคอนเทนเนอร์ที่แนะนำ 2 GB สำหรับการติดตั้งใช้งานจริงขนาดเล็ก | ไม่มีขั้นต่ำ RAM อย่างเป็นทางการที่เทียบกันตรงๆ ได้ |
เครื่องมือไหนเหมาะกับสแต็กไหน?
ตัวเลือกที่ดีที่สุดเปลี่ยนไปตามว่าใครเป็นคนดูแล IdP และแอปพลิเคชันเชื่อมต่อกับมันอย่างไร
ตัวเลือกที่ดีที่สุดสำหรับ homelab
Authentik คือค่าเริ่มต้นสำหรับ homelab ที่แอปพลิเคชันส่วนใหญ่รองรับ OIDC หรือ SAML อยู่แล้ว มันให้ผู้ให้บริการข้อมูลประจำตัวเต็มรูปแบบโดยไม่บังคับให้คุณรับโมเดล IAM ที่กว้างกว่าของ Keycloak ถ้าสแต็กส่วนใหญ่ต้องการหน้าล็อกอินที่ reverse proxy แทน SSO ในตัว Authelia อาจเป็นตัวเลือกที่ง่ายกว่า
ตัวเลือกที่ดีที่สุดสำหรับสแต็กธุรกิจขนาดเล็ก
Authentik เหมาะกับสแต็กแอปพลิเคชันภายในขนาดเล็กส่วนใหญ่ โดยเฉพาะเมื่อเป้าหมายคือชั้นข้อมูลประจำตัวชั้นเดียวสำหรับเครื่องมืออย่าง Grafana, Gitea, Nextcloud และ Vaultwarden ส่วน Keycloak จะน่าสนใจขึ้นเมื่อไดเรกทอรีที่มีอยู่ realm หลายตัว หรือนโยบายการอนุญาตที่ลึกกว่าเป็นส่วนหนึ่งของข้อกำหนด
ตัวเลือกที่ดีที่สุดสำหรับนักพัฒนาและผลิตภัณฑ์ SaaS
ZITADEL เหมาะที่สุดเมื่อการยืนยันตัวตนเป็นส่วนหนึ่งของผลิตภัณฑ์ที่คุณกำลังสร้าง โมเดลองค์กร ระบบหลายผู้เช่า API และพื้นผิวการทำงานอัตโนมัติมีความหมายมากขึ้นเมื่อผู้ใช้และผู้เช่าต้องถูกสร้างจากโค้ดของแอปพลิเคชันมากกว่าผ่านแผงผู้ดูแลระบบเป็นหลัก
ตัวเลือกที่ดีที่สุดสำหรับทีมองค์กรหรือทีมที่เน้นการปฏิบัติตามข้อกำหนด
Keycloak สมเหตุสมผลเมื่อรายการข้อกำหนดมีการรวมไดเรกทอรีที่ซับซ้อน realm หลายตัว นโยบายการอนุญาตแบบละเอียด และทีมที่ดูแลความซับซ้อนของ IAM ที่เพิ่มขึ้นได้ การโฮสต์ Keycloak เองไม่ได้ทำให้สภาพแวดล้อมสอดคล้องกับข้อกำหนดโดยอัตโนมัติ การสำรองข้อมูล ความพร้อมใช้งาน การบันทึกล็อก การทบทวนสิทธิ์การเข้าถึง และการควบคุมการเปลี่ยนแปลงยังคงเป็นหน้าที่ของทีมคุณ
ตัวเลือกที่ดีที่สุดสำหรับแอปที่ไม่มี SSO ในตัว
Authelia เหมาะที่สุดอย่างชัดเจนเมื่อการยืนยันตัวตนต้องเกิดขึ้นก่อนที่คำขอจะไปถึงแอปพลิเคชัน มันทำงานได้ดีเป็นพิเศษกับ reverse proxy ที่ปกป้องเครื่องมือภายในรุ่นเก่า แดชบอร์ด และบริการที่ไม่รองรับ OIDC หรือ SAML ด้วยตัวเอง
ส่วนที่ยากของการโฮสต์ SSO เอง
เมื่อ SSO กลายเป็นข้อบังคับ ความผิดพลาดในการตั้งค่าหรือการกู้คืนที่ล้มเหลวอาจกระทบแอปพลิเคชันหลายตัวพร้อมกัน
การติดตั้งและการตั้งค่า
การทำให้คอนเทนเนอร์รันได้เป็นแค่ก้าวแรก DNS, TLS, URI สำหรับเปลี่ยนเส้นทาง, claim ในโทเค็น, การแมปกลุ่ม, การส่งอีเมล และการเข้าถึงเพื่อกู้คืน คือจุดที่การติดตั้ง SSO เริ่มกลายเป็นโครงสร้างพื้นฐานมากกว่าแค่แอป Docker อีกตัว
ทรัพยากรเซิร์ฟเวอร์
IdP เป็นเพียงส่วนหนึ่งของงบทรัพยากร PostgreSQL, reverse proxy, worker, การแฮชรหัสผ่าน, ล็อก และการซิงก์ไดเรกทอรี ล้วนแย่ง CPU และหน่วยความจำกันได้เมื่อใช้ VPS เครื่องเดียวกัน
การจัดการฐานข้อมูลและการสำรองข้อมูล
Authentik, ZITADEL และการติดตั้ง Keycloak ใช้งานจริงทั่วไปพึ่งพาฐานข้อมูล สำรองฐานข้อมูลนั้นไว้นอกเซิร์ฟเวอร์ จดขั้นตอนการกู้คืนไว้ และทดสอบการกู้คืน งานสำรองข้อมูลที่สำเร็จไม่ใช่สิ่งเดียวกับกระบวนการกู้คืนที่ใช้งานได้จริง
ความเสี่ยงจากการถูกล็อกออกและการกู้คืน
URI เปลี่ยนเส้นทางที่ผิด ความลับไคลเอนต์ที่หมดอายุ การเชื่อมต่อไดเรกทอรีที่ขาด หรือนโยบายที่เข้มงวดเกินไป อาจล็อกผู้ดูแลระบบออกไปพร้อมกับทุกคน เตรียมเส้นทางกู้คืนที่ไม่พึ่งพาโฟลว์ยืนยันตัวตนที่คุณกำลังพยายามซ่อม
การรักษาให้ IdP พร้อมใช้งาน
เมื่อ IdP ล่ม เซสชันแอปพลิเคชันที่มีอยู่ไม่ได้จบลงทันทีทั้งหมดเสมอไป เซสชันที่มีอยู่อาจดำเนินต่อไปจนกว่าโทเค็นหรือคุกกี้ของมันจะหมดอายุ แต่การล็อกอินใหม่และการรีเฟรชโทเค็นอาจล้มเหลว ทดสอบโหมดล้มเหลวนี้ก่อนบังคับใช้ SSO ทั่วทั้งสแต็ก
เมื่อไรที่คุณไม่ควรโฮสต์ SSO เอง
การโฮสต์เองจะไม่คุ้มอีกต่อไปเมื่อทีมของคุณไม่สามารถกู้คืนและดูแลชั้นข้อมูลประจำตัวได้ในระดับความน่าเชื่อถือที่แอปพลิเคชันของคุณต้องการ
เมื่อไรที่บริการข้อมูลประจำตัวแบบจัดการให้ปลอดภัยกว่า
บริการข้อมูลประจำตัวแบบจัดการให้คุ้มค่าที่จะจ่ายเมื่อต้นทุนการดูแล IdP สูงกว่าการควบคุมที่คุณได้จากการโฮสต์เอง บริการอย่าง Auth0, Clerk, WorkOS และ Microsoft Entra ID ย้ายภาระด้านความพร้อมใช้งานของแพลตฟอร์ม การแพตช์ และการบำรุงรักษาโครงสร้างพื้นฐานส่วนใหญ่ไปที่ผู้ให้บริการ
คุณยังคงรับผิดชอบการตั้งค่าแอปพลิเคชัน สิทธิ์ และการวางแผนกู้คืน แต่ไม่ต้องรับผิดชอบการทำให้ตัวแพลตฟอร์มข้อมูลประจำตัวออนไลน์อยู่เสมออีกต่อไป
เมื่อไรที่ทีมของคุณรับมือกับดาวน์ไทม์ไม่ไหว
ถ้าไม่มีใครในทีมที่กู้คืน IdP ซ่อม PostgreSQL เปลี่ยนความลับที่หมดอายุ หรือวินิจฉัยการเชื่อมต่อการรวมที่ล้มเหลวได้ระหว่างเกิดเหตุขัดข้อง การโฮสต์ข้อมูลประจำตัวเองอาจเป็นข้อแลกเปลี่ยนด้านการดำเนินงานที่ผิดพลาด
ความล้มเหลวกว้างกว่าแอปพลิเคชันเดียวที่ใช้งานไม่ได้ การล็อกอินใหม่และการรีเฟรชโทเค็นในหลายแอปพลิเคชันอาจล้มเหลวพร้อมกัน
เมื่อไรที่ข้อกำหนดด้านการปฏิบัติตามสูงเกินไป
ข้อมูลประจำตัวแบบโฮสต์เองใช้ในสภาพแวดล้อมที่มีการกำกับดูแลได้ แต่การรันซอฟต์แวร์เองไม่ได้สร้างการควบคุมหรือหลักฐานที่ผู้ตรวจสอบคาดหวังโดยอัตโนมัติ ทีมของคุณยังคงรับผิดชอบการบันทึกล็อก การทบทวนสิทธิ์การเข้าถึง การสำรองข้อมูล การจัดการการเปลี่ยนแปลง ความพร้อมใช้งาน การรับมือเหตุการณ์ และเอกสารใดๆ ที่กรอบข้อกำหนดที่เกี่ยวข้องต้องการ
SSO แบบโฮสต์เองไม่ใช่สัญลักษณ์แสดงสถานะ ถ้าทีมของคุณดูแลชั้นข้อมูลประจำตัวอย่างปลอดภัยไม่ได้ การจ่ายเงินให้บริการข้อมูลประจำตัวแบบจัดการให้อาจเป็นการตัดสินใจทางวิศวกรรมที่ดีกว่า
Cloudzy ช่วยตรงไหน
Cloudzy เปลี่ยนชั้นการติดตั้งใช้งาน แต่ไม่ได้ตัดงานตั้งค่าข้อมูลประจำตัวและงานดูแลระบบที่อธิบายไว้ข้างต้นออกไป
ปัญหาของการติดตั้ง SSO ด้วยตนเอง
การติดตั้ง SSO ด้วยตนเองหมายถึงการเตรียมเซิร์ฟเวอร์ ติดตั้งแอปพลิเคชันและฐานข้อมูล ตั้งค่า reverse proxy ตั้งค่า DNS และ TLS แล้วจึงค่อยเริ่มตั้งค่าข้อมูลประจำตัวจริงๆ ไม่มีขั้นตอนไหนแทนที่งาน OIDC, SAML, ไดเรกทอรี หรือนโยบายที่ตามมาทีหลังได้
ติดตั้ง SSO ในคลิกเดียวบน Cloudzy
Cloudzy มีการติดตั้งแบบคลิกเดียวสำหรับ Authentik และ Keycloak แอป Authentik แบบคลิกเดียวอยู่ในมาร์เก็ตเพลสของ Cloudzy แอป Keycloak แบบคลิกเดียวก็อยู่ในมาร์เก็ตเพลสของ Cloudzy เช่นกัน ตอนนี้ ZITADEL ยังไม่อยู่ในมาร์เก็ตเพลส ดังนั้นให้ติดตั้งด้วยชุด Docker Compose ของมันบน VPS มาตรฐาน การติดตั้งแบบคลิกเดียวทำให้แอปพลิเคชันพื้นฐานรันได้ ส่วนการตั้งค่าข้อมูลประจำตัว DNS การสำรองข้อมูล การอัปเกรด นโยบาย และการทดสอบกู้คืนยังคงอยู่ในความควบคุมของคุณ
พัฒนาบน Linux VPS พร้อมสิทธิ์รูท, NVMe และพลัง AMD EPYC
ดูแพ็กเกจ Linuxเมื่อไรควรใช้ VPS แยกสำหรับ IdP ของคุณ
การโฮสต์ IdP ร่วมกับแอปพลิเคชันของคุณเป็นเรื่องสมเหตุสมผลสำหรับ homelab ที่ยอมรับดาวน์ไทม์ได้ สำหรับสแต็กที่สำคัญต่อธุรกิจ การแยกผู้ให้บริการข้อมูลประจำตัวออกมาจะกำจัดโดเมนความล้มเหลวร่วมที่เห็นได้ชัด การรีสตาร์ต ใช้ทรัพยากรจนหมด หรือการถูกเจาะเซิร์ฟเวอร์แอปพลิเคชันจะไม่ทำให้ชั้นข้อมูลประจำตัวล่มตามไปด้วยอีกต่อไป
VPS แยกไม่ใช่สิ่งเดียวกับความพร้อมใช้งานสูง แต่มันให้ IdP มีงบทรัพยากร ตารางบำรุงรักษา และขอบเขตการกู้คืนเป็นของตัวเอง
คำแนะนำการกำหนดขนาด VPS
กำหนดขนาดให้ทั้งสแต็ก ไม่ใช่แค่โปรเซส IdP โดยเฉพาะเมื่อ PostgreSQL และ reverse proxy ใช้ VPS เดียวกัน
ความต้องการ VPS ของ Authentik
เอกสาร Docker Compose อย่างเป็นทางการของ Authentik กำหนดให้โฮสต์มี CPU อย่างน้อย 2 คอร์และ RAM 2 GB นั่นคือจุดเริ่มต้นที่ถูกต้องสำหรับการติดตั้งขนาดเล็ก เผื่อทรัพยากรเซิร์ฟเวอร์เพิ่มเมื่อ PostgreSQL, outpost เพิ่มเติม, การซิงก์ไดเรกทอรี หรือทราฟฟิกล็อกอินที่หนักขึ้นใช้โฮสต์เดียวกัน
ความต้องการ VPS ของ ZITADEL
การติดตั้ง Docker Compose อย่างเป็นทางการของ ZITADEL กำหนดให้โฮสต์มี RAM อย่างน้อย 2 GB กำหนดขนาด VPS แบบรวมทุกอย่างสำหรับ ZITADEL, Login UI ของมัน, PostgreSQL และ reverse proxy รวมกัน แทนที่จะมองบริการ Go แยกเดี่ยวๆ
ความต้องการ VPS ของ Keycloak
เอกสารคอนเทนเนอร์ของ Keycloak แนะนำขีดจำกัดหน่วยความจำ 2 GB สำหรับการติดตั้ง Keycloak ขนาดเล็กที่พร้อมใช้งานจริง ตัวเลขนั้นใช้กับคอนเทนเนอร์ Keycloak เอง ไม่ใช่ VPS ทั้งเครื่องที่รัน PostgreSQL ด้วย
ถ้า Keycloak และ PostgreSQL ใช้ VPS เครื่องเดียวกัน RAM ระบบ 4 GB เป็นจุดเริ่มต้นที่สมเหตุสมผล ให้ถือว่านี่เป็นแนวทางเชิงปฏิบัติสำหรับโฮสต์ ไม่ใช่ขั้นต่ำอย่างเป็นทางการของ Keycloak
ความต้องการ VPS ของ Authelia
Authelia ไม่ได้เผยแพร่ขั้นต่ำเซิร์ฟเวอร์ 1 GB หรือ 2 GB ที่เทียบกันตรงๆ ได้ กำหนดขนาดโฮสต์สำหรับ Authelia ร่วมกับ reverse proxy แบ็กเอนด์จัดเก็บข้อมูล ไดเรกทอรีผู้ใช้ และบริการอื่นใดที่ใช้เครื่องร่วมกัน
โดยทั่วไป Authelia ใช้ทรัพยากรน้อยกว่าการรัน IdP เต็มรูปแบบควบคู่กับ PostgreSQL แต่ความต้องการ VPS จริงขึ้นอยู่กับส่วนที่เหลือของสแต็ก
ตัวอย่างการตั้งค่า: Authentik กับ Vaultwarden
Vaultwarden เพิ่มการรองรับ SSO แบบ OpenID Connect ในตัวในเวอร์ชัน 1.35.0 เมื่อเดือนธันวาคม 2025 Authentik เป็นตัวอย่างที่มีประโยชน์เพราะการเชื่อมต่อนี้เผยให้เห็นองค์ประกอบ OIDC ที่คุณจะพบกับแอปพลิเคชันอื่นด้วย ได้แก่ URI เปลี่ยนเส้นทาง ข้อมูลรับรองไคลเอนต์ สโคป URL ผู้ออก และการเข้าถึงเพื่อกู้คืน
การตั้งค่า Authentik พื้นฐาน
ใน Authentik:
- สร้างการแมปสโคปอีเมลแบบกำหนดเองสำหรับ Vaultwarden Vaultwarden กำหนดให้สโคป email ต้องคืนค่า email_verified: true หรือไม่คืนค่า email_verified เลย ในขณะที่สโคปอีเมลค่าเริ่มต้นของ Authentik ปัจจุบันคืนค่า false
- สร้างคู่แอปพลิเคชันและผู้ให้บริการ OAuth2/OpenID Connect
- เพิ่ม https://vault.example.com/identity/connect/oidc-signin เป็น URI เปลี่ยนเส้นทางแบบเข้มงวดประเภท Authorization
- เลือกคีย์ลงนามที่มีอยู่ตัวใดก็ได้
- จด Client ID, Client Secret และ slug ของแอปพลิเคชันไว้
- ตั้งอายุโทเค็นการเข้าถึงให้มากกว่าห้านาที
- เพิ่มการแมป offline_access ของ Authentik เข้าไปในสโคปที่เลือก
- แทนที่การแมปอีเมลค่าเริ่มต้นด้วยการแมปอีเมลที่ยืนยันแล้วแบบกำหนดเองจากขั้นตอนที่ 1
การตั้งค่า OIDC พื้นฐานของ Vaultwarden
ใช้:
DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=trueแทนที่โดเมนตัวอย่าง slug ของแอปพลิเคชัน client ID และ client secret ด้วยค่าจากการติดตั้งของคุณเอง แล้วรีสตาร์ต Vaultwarden
สิ่งที่ควรทดสอบก่อนบังคับใช้ SSO
ปล่อยให้ SSO_ONLY เป็น false ระหว่างที่คุณทดสอบการล็อกอิน ล็อกเอาต์ รีเฟรชโทเค็น จับคู่บัญชี และการกู้คืน และทดสอบด้วยว่าจะเกิดอะไรขึ้นเมื่อ Authentik ใช้งานไม่ได้ชั่วคราว
เมื่อทั้ง SSO และการกู้คืนทำงานตามที่คาด คุณจึงตัดสินใจได้ว่าการบังคับใช้ SSO กับทุกการล็อกอินเหมาะกับการติดตั้งของคุณหรือไม่
แนวคิด OIDC เดียวกันนี้ใช้ได้กับแอปพลิเคชันโฮสต์เองอื่นๆ แต่ URI เปลี่ยนเส้นทาง สโคป claim และสัญญาอนุญาตต่างกัน ตรวจสอบเอกสาร SSO ของแต่ละแอปพลิเคชันแทนการคัดลอกการตั้งค่า Vaultwarden ไปใช้ตรงๆ
เมื่อไรที่ Authelia ดีกว่า IdP เต็มรูปแบบ
Authelia จะน่าสนใจขึ้นเมื่อแอปพลิเคชันไม่จำเป็นต้องเข้าใจผู้ให้บริการข้อมูลประจำตัวเลย
การยืนยันตัวตนที่ reverse proxy
Authelia ออกแบบมาเพื่อปกป้องแอปพลิเคชันที่ชั้น reverse proxy เป็นหลัก คุณกำหนดกฎควบคุมการเข้าถึง แล้ว Authelia จะตัดสินว่าคำขอควรไปถึงแบ็กเอนด์หรือไม่ก่อนที่ตัวแอปพลิเคชันจะจัดการการยืนยันตัวตนเอง
การปกป้องแอปที่ไม่มี OIDC
วิธีนี้มีประโยชน์กับเครื่องมือภายในรุ่นเก่า แดชบอร์ด และบริการที่ไม่รองรับ OIDC หรือ SAML แทนที่จะแก้ไขแต่ละแอปพลิเคชัน คุณสามารถวางการยืนยันตัวตนไว้ข้างหน้ามันที่ reverse proxy ได้
Authelia ทำหน้าที่เป็นผู้ให้บริการ OIDC ได้ด้วย แต่การยืนยันตัวตนที่ reverse proxy ยังคงเป็นจุดแข็งหลักของมัน
การใช้ Authelia ร่วมกับ Authentik
คุณใช้ Authentik กับแอปพลิเคชันที่รองรับ OIDC หรือ SAML และใช้ Authelia กับแอปพลิเคชันที่ต้องยืนยันตัวตนที่ reverse proxy ได้
คุณไม่จำเป็นต้องใช้ทั้งสองตัวเสมอไป Authentik ก็รองรับการปกป้องแอปพลิเคชันผ่านพร็อกซีเช่นกัน ดังนั้นการใช้ Authelia ควบคู่ไปด้วยจะสมเหตุสมผลก็ต่อเมื่อเวิร์กโฟลว์ reverse proxy ของ Authelia แก้ปัญหาส่วนใดส่วนหนึ่งของสแต็กคุณได้สะอาดกว่า
คำถามที่พบบ่อย
Authentik ดีกว่า Keycloak ไหม?
สำหรับ homelab และสแต็กแอปพลิเคชันโฮสต์เองขนาดเล็กส่วนใหญ่ Authentik เข้าถึงได้ง่ายกว่า เวิร์กโฟลว์การดูแลระบบของมันเน้นไปที่แอปพลิเคชัน ผู้ให้บริการ กลุ่ม และนโยบาย โดยไม่เปิดเผยความซับซ้อนของ IAM มากขนาดนั้นในคราวเดียว
Keycloak สมเหตุสมผลกว่าเมื่อคุณต้องการการรวมที่ลึกกว่า โมเดล realm หรือ Authorization Services ของมันโดยเฉพาะ Authentik คือค่าเริ่มต้นที่แข็งแกร่งกว่าสำหรับ SSO แบบโฮสต์เองที่เรียบง่ายกว่า ส่วน Keycloak เหมาะกับสภาพแวดล้อมที่ต้องการการควบคุมเพิ่มเติมเหล่านั้น
ZITADEL ดีกว่า Keycloak ไหม?
ZITADEL เหมาะกว่าเมื่อคุณกำลังสร้างผลิตภัณฑ์และต้องการข้อมูลประจำตัวที่ขับเคลื่อนด้วย API องค์กร และระบบหลายผู้เช่า Keycloak เหมาะกว่าเมื่อคุณต้องการโมเดลการอนุญาตที่ลึกกว่า การควบคุมการรวมที่ครอบคลุม หรือสภาพแวดล้อมที่สร้างขึ้นรอบ Keycloak อยู่แล้ว
Authentik กับ Authelia ต่างกันอย่างไร?
Authentik คือผู้ให้บริการข้อมูลประจำตัวเต็มรูปแบบที่สร้างขึ้นรอบผู้ใช้ กลุ่ม แอปพลิเคชัน ผู้ให้บริการ โฟลว์ และนโยบาย แอปพลิเคชันเชื่อมต่อกับมันได้โดยตรงผ่านโปรโตคอลอย่าง OIDC และ SAML
Authelia มีศูนย์กลางอยู่ที่การยืนยันตัวตนและการควบคุมการเข้าถึงที่ reverse proxy มันมีผู้ให้บริการ OIDC ด้วย แต่การปกป้องที่ reverse proxy ยังคงเป็นกรณีใช้งานหลัก
เลือก Authentik เมื่อแอปพลิเคชันเชื่อมต่อกับ IdP โดยตรง เลือก Authelia เมื่อการยืนยันตัวตนส่วนใหญ่ต้องเกิดขึ้นก่อนที่ทราฟฟิกจะไปถึงแอปพลิเคชัน
รัน Authentik บน VPS 1 GB ได้ไหม?
ไม่ใช่ในฐานะจุดเริ่มต้นที่รองรับ เอกสาร Docker Compose ปัจจุบันของ Authentik กำหนด CPU อย่างน้อย 2 คอร์และ RAM 2 GB การติดตั้งหลักปัจจุบันใช้เซิร์ฟเวอร์ Authentik, worker และ PostgreSQL ส่วน Redis ถูกถอดออกทั้งหมดใน Authentik 2025.10
ใช้ 2 GB เป็นจุดเริ่มต้นขั้นต่ำสำหรับการติดตั้งขนาดเล็ก และเผื่อเพิ่มเมื่อบริการอื่นใช้เครื่องร่วมกัน
Vaultwarden รองรับ OIDC SSO ไหม?
รองรับ Vaultwarden เพิ่มการรองรับ SSO แบบ OpenID Connect ในเวอร์ชัน 1.35.0 เมื่อเดือนธันวาคม 2025 โดยต้องใช้ผู้ให้บริการ OIDC ภายนอก เช่น Authentik, Keycloak หรือ ZITADEL
การตั้งค่าที่แน่นอนขึ้นอยู่กับผู้ให้บริการ สำหรับ Authentik รุ่นปัจจุบัน การเชื่อมต่อตามเอกสารประกอบด้วยการแมปสโคปอีเมลที่ยืนยันแล้วแบบกำหนดเอง, offline_access, ข้อมูลรับรองไคลเอนต์ และ URL ผู้ออกของแอปพลิเคชัน Authentik
ควรรัน IdP บน VPS เดียวกับแอปของฉันไหม?
สำหรับ homelab ที่ยอมรับดาวน์ไทม์ได้ การโฮสต์รวมกันอาจสมเหตุสมผล สำหรับแอปพลิเคชันที่สำคัญต่อธุรกิจ VPS แยกให้ผู้ให้บริการข้อมูลประจำตัวมีงบทรัพยากรของตัวเอง และนำเซิร์ฟเวอร์แอปพลิเคชันออกจากโดเมนความล้มเหลวร่วม
สิ่งนี้ไม่ได้สร้างความพร้อมใช้งานสูงด้วยตัวมันเอง แต่การรีสตาร์ตเซิร์ฟเวอร์แอปพลิเคชัน ปัญหาทรัพยากร หรือการถูกเจาะจะไม่ทำให้ IdP ล่มตามไปโดยอัตโนมัติอีกต่อไป
SSO แบบโฮสต์เองตัวไหนใช้ง่ายที่สุด?
Authentik คือจุดเริ่มต้นที่ง่ายที่สุดสำหรับคนส่วนใหญ่ที่เชื่อมต่อแอปพลิเคชันโฮสต์เองที่มีอยู่ หน้าจัดการระบบของมันทำให้แอปพลิเคชัน ผู้ให้บริการ กลุ่ม และนโยบายเข้าถึงได้ง่ายกว่าโมเดล realm และการอนุญาตที่กว้างกว่าของ Keycloak
Authelia อาจง่ายกว่าเมื่อคุณต้องการแค่การยืนยันตัวตนที่ reverse proxy ส่วน ZITADEL สมเหตุสมผลกว่าเมื่อคนที่ตั้งค่าข้อมูลประจำตัวเป็นนักพัฒนาที่ทำงานผ่าน API เป็นหลัก
การสนทนา
ความคิดเห็น
เข้าสู่ระบบเพื่อร่วมสนทนา