เปรียบเทียบ Keycloak vs authentik vs Zitadel บน VPS

เซิร์ฟเวอร์ SSO ใดที่เหมาะกับ VPS หนึ่งเครื่อง

Keycloak, authentik และ Zitadel คือเซิร์ฟเวอร์ Single Sign-On (SSO) แบบ self-hosted ที่มักถูกกล่าวถึงเมื่อต้องการใช้การล็อกอินชุดเดียวสำหรับทุกแอปพลิเคชันบนเซิร์ฟเวอร์ แต่บน VPS ขนาดเล็ก ทั้งสามตัวนี้ไม่สามารถใช้แทนกันได้ authentik เป็นตัวเลือกเริ่มต้นที่ปลอดภัยสำหรับเซิร์ฟเวอร์ที่รันแอปพลิเคชันประมาณ 3-4 ตัว เนื่องจากเป็นตัวเดียวในสามตัวนี้ที่สามารถวางหน้าจอล็อกอินไว้หน้าแอปพลิเคชันที่ไม่มีระบบล็อกอินของตัวเองได้ Keycloak เป็นตัวเลือกที่เหมาะสมเมื่อแอปพลิเคชันทุกตัวที่คุณต้องการปกป้องรองรับโปรโตคอลมาตรฐานอยู่แล้ว และคุณมีหน่วยความจำเพียงพอสำหรับ Java virtual machine (JVM) ส่วน Zitadel ถูกสร้างขึ้นมาสำหรับนักพัฒนาที่ต้องการส่งมอบผลิตภัณฑ์ผ่าน API และเป็นตัวเลือกที่ผมไม่แนะนำให้ติดตั้งหากมี RAM ต่ำกว่า 4 GB

เลือกให้แน่ชัดก่อนเริ่มติดตั้ง เมื่อคุณเลือกได้แล้ว ขั้นตอนการติดตั้ง authentik บน VPS จะอธิบายวิธีการตั้งค่าแบบทีละขั้นตอน

แต่ละตัวใช้ RAM จริงเท่าไหร่

ให้เริ่มพิจารณาจากทรัพยากรขั้นต่ำ เพราะเป็นตัวกำหนดรายการที่เลือกได้ก่อนจะพิจารณาฟีเจอร์ใดๆ ตัวเลขด้านล่างนี้เป็นข้อมูลที่แต่ละโปรเจกต์เผยแพร่อย่างเป็นทางการ ณ เดือนสิงหาคม 2026 ซึ่งเป็นคำแนะนำจากผู้พัฒนา ไม่ใช่ผลลัพธ์จากการทดสอบโหลด (load test)

[
  {
    "label": "authentik",
    "vendor_min_ram_mb": 2048,
    "base_containers": 3
  },
  {
    "label": "Keycloak",
    "vendor_min_ram_mb": 1250,
    "base_containers": 2
  },
  {
    "label": "Zitadel",
    "vendor_min_ram_mb": 2048,
    "base_containers": 4
  }
]

หน้าติดตั้ง Docker Compose ของ authentik ระบุว่าต้องการ "โฮสต์ที่มี CPU อย่างน้อย 2 คอร์ และ RAM 2 GB" ซึ่งคิดเป็น 2048 MB และไฟล์ compose ที่เผยแพร่จะรันคอนเทนเนอร์จำนวน 3 ตัว ได้แก่ PostgreSQL, เซิร์ฟเวอร์ และ worker

Keycloak ระบุตัวเลขที่เฉพาะเจาะจงที่สุดใน 3 โดยคู่มือการกำหนดขนาดระบุว่า "หน่วยความจำพื้นฐานสำหรับ Pod รวมถึงแคชของข้อมูล Realm และ session ที่แคชไว้ 10,000 รายการ คือ 1250 MB" ค่า 1250 MB นี้ครอบคลุมเฉพาะตัวกระบวนการ Java เท่านั้น ยังไม่รวมฐานข้อมูล หน้าเดียวกันนี้อธิบายว่าเหตุใดขีดจำกัดของคอนเทนเนอร์จึงสำคัญมาก: Keycloak จะใช้หน่วยความจำ 70% ของขีดจำกัดเป็น heap และใช้หน่วยความจำ non-heap อีกประมาณ 300 MB หากกำหนดให้คอนเทนเนอร์มี 1 GB ระบบจะคำนวณ heap ได้ประมาณ 717 MB ในขณะที่ยังคงต้องใช้ non-heap อีก 300 MB ทำให้ขีดจำกัดถูกใช้จนหมดก่อนจะมีข้อมูล session ใดๆ เข้าไปอยู่ในแคช

หน้า compose ของ Zitadel ก็ระบุว่าต้องการ 2 GB หรือ 2048 MB เช่นกัน แต่ตัวเลขนั้นสำหรับการรันครั้งแรกเท่านั้น ควรดูข้อมูลจากหน้า production จะดีกว่า กระบวนการของ Zitadel เองต้องการ "RAM ประมาณ 512 MB และสามารถทำงานได้ด้วย CPU ไม่ถึงหนึ่งคอร์" ส่วนฐานข้อมูลคือส่วนที่ใช้ทรัพยากรสูง: "ต้องการ CPU ประมาณหนึ่งคอร์ต่อ 100 คำขอต่อวินาที (req/s) และ RAM 4 GB ต่อคอร์" สำหรับการทำ password hashing นั้นต้องการ "CPU 4 คอร์" เพราะการล็อกอินพร้อมกันจำนวนมากจะทำให้ CPU พุ่งสูงขึ้น ไฟล์ compose เวอร์ชัน v4 อย่างเป็นทางการจะรันคอนเทนเนอร์จำนวน 4 ตัวก่อนที่คุณจะเพิ่มบริการใดๆ ได้แก่ Traefik เป็นพร็อกซี, Zitadel API, คอนเทนเนอร์ Login UI แยกต่างหาก และ PostgreSQL ส่วน Redis และ OpenTelemetry collector จะอยู่ในโปรไฟล์ compose แบบเลือกเปิดใช้งานได้

สรุปคือ Keycloak และ authentik สามารถรันบน VPS ขนาด 4 GB ได้โดยยังมีพื้นที่เหลือสำหรับแอปที่คุณต้องการปกป้อง ส่วน Zitadel จะเริ่มทำงานได้บน 2 GB แต่จะแย่ง RAM กับ PostgreSQL ของตัวเองทุกครั้งที่มีการล็อกอิน ผมไม่แนะนำให้รัน Zitadel บนเครื่องที่มี RAM ต่ำกว่า 4 GB และหากเครื่องนั้นต้องโฮสต์แอปอื่นๆ ด้วย ผมแนะนำให้ใช้ 8 GB

สิ่งที่แต่ละตัวทำงานจริงบนเครื่องของคุณ

authentik ประกอบด้วย PostgreSQL และอิมเมจเดียวกันสองชุด คือส่วน server และส่วน worker โดย server จะทำหน้าที่ตอบสนอง HTTP และเก็บ embedded outpost ไว้ ส่วน worker จะรันงานเบื้องหลัง เช่น การซิงค์ directory และการส่งอีเมล การติดตั้งตามมาตรฐานนั้นทำได้สั้นๆ

wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

server จะเปิดพอร์ต 9000 และ 9443 การเข้าใช้งานพอร์ต 9000 ครั้งแรกจะเป็นการเริ่มขั้นตอนตั้งค่าเริ่มต้น ซึ่งคุณจะต้องกำหนดรหัสผ่านสำหรับผู้ใช้เริ่มต้นคือ akadmin ควรติดตั้ง reverse proxy ที่มี certificate จริงไว้ด้านหน้าก่อนที่จะเปิดให้เข้าถึงพอร์ตดังกล่าวจากอินเทอร์เน็ต

Keycloak ประกอบด้วยหนึ่งกระบวนการทำงาน (process) บวกกับฐานข้อมูลที่คุณต้องจัดเตรียมไว้ การเริ่มต้นใช้งานอย่างรวดเร็วทำได้โดยใช้คอนเทนเนอร์เดียว

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.7.1 start-dev

start-dev มีไว้สำหรับการทดสอบดูการทำงานเท่านั้น มันทำงานร่วมกับฐานข้อมูลสำหรับการพัฒนาในเครื่องและไม่มี TLS (transport layer security) ดังนั้นคอนเทนเนอร์ที่เริ่มด้วยวิธีนี้และถูกลบในภายหลังจะทำให้ realm ของคุณหายไปด้วย สำหรับการใช้งานจริงให้ใช้ start แทน โดยเชื่อมต่อกับ PostgreSQL จริงผ่าน KC_DB และใช้ชื่อโฮสต์สาธารณะผ่าน KC_HOSTNAME คู่มือการใช้งานจริงของ Keycloak ยังระบุว่าการสื่อสารทั้งหมดเข้าและออกจากเซิร์ฟเวอร์จำเป็นต้องผ่านช่องทางที่ปลอดภัย ดังนั้น HTTPS จึงเป็นสิ่งที่ขาดไม่ได้

Zitadel คือชุด stack สี่คอนเทนเนอร์ตามที่อธิบายไว้ข้างต้น

mkdir zitadel-compose && cd zitadel-compose
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/docker-compose.yml
curl -fsSLO https://raw.githubusercontent.com/zitadel/zitadel/main/deploy/compose/.env.example
cp .env.example .env
docker compose up -d --wait

กำหนดค่า ZITADEL_MASTERKEY ใน .env ก่อนการเริ่มทำงานครั้งแรก นี่คือคีย์ความยาว 32 ตัวอักษรที่ Zitadel ใช้สำหรับเข้ารหัสความลับในฐานข้อมูล ดังนั้นหากทำคีย์นี้หายจะหมายถึงการสูญเสียสิทธิ์เข้าถึงความลับเหล่านั้น หากคุณยังใหม่กับการรัน stack เหล่านี้ พื้นฐาน Docker Compose สำหรับ VPS จะครอบคลุมถึงการเลือก volume และนโยบายการ restart ซึ่งเป็นตัวตัดสินว่า identity provider ของคุณจะยังคงอยู่หลังจากการรีบูตหรือไม่

แต่ละตัวรองรับโปรโตคอลใดบ้าง

ทั้งสามตัวรองรับ OpenID Connect (OIDC) ซึ่งเป็นเลเยอร์การล็อกอินที่ทำงานอยู่บน OAuth 2.0 ที่แอปพลิเคชันสมัยใหม่ใช้งาน และทั้งสามตัวยังรองรับ SAML 2.0 (Security Assertion Markup Language) ซึ่งเป็นมาตรฐานรุ่นเก่าที่ซอฟต์แวร์ระดับองค์กรยังคงใช้งานอยู่ ความแตกต่างที่แท้จริงอยู่ที่ LDAP (Lightweight Directory Access Protocol) ซึ่งคำเดียวนี้ครอบคลุมการทำงานที่ตรงข้ามกันสองอย่าง

การอ่านจาก LDAP หมายถึงเซิร์ฟเวอร์ SSO จะตรวจสอบรหัสผ่านเทียบกับไดเรกทอรีที่คุณใช้งานอยู่แล้ว Keycloak ทำสิ่งนี้ผ่านฟีเจอร์ user federation ส่วน Zitadel ก็ทำได้เช่นกัน โดยเอกสารประกอบอธิบายวิธี "เชื่อมต่อเซิร์ฟเวอร์ LDAP ในฐานะ identity provider ใน ZITADEL"

การให้บริการ LDAP หมายถึงแอปพลิเคชันที่รองรับเฉพาะ LDAP สามารถทำการ bind เข้ากับเซิร์ฟเวอร์ SSO ของคุณเสมือนว่ามันเป็นไดเรกทอรี มีเพียง authentik เท่านั้นที่ทำได้ โดย LDAP provider ของมันจะทำให้ "ผู้ใช้และกลุ่มทั้งหมดในฐานข้อมูลของ authentik สามารถค้นหาได้ผ่านไดเรกทอรี LDAP" โดยใช้ LDAP outpost เฉพาะทาง และรองรับ LDAPS บนพอร์ต 636 การทำงานนี้เป็นแบบอ่านอย่างเดียว (read-only) ดังนั้นการ bind และการค้นหาจึงใช้งานได้ แต่การเขียนข้อมูลไม่สามารถทำได้ โดยจะต้องต่อรหัสผ่านแบบใช้ครั้งเดียว (one-time code) ไว้ท้ายรหัสผ่านด้วยเครื่องหมายอัฒภาค ดังที่แสดงใน password;123456 และไม่รองรับ SMS authenticator ในระหว่างการ bind

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

แล้วแอปที่ไม่มีระบบล็อกอินเลยล่ะ?

Forward auth คือคำตอบ และเป็นสถานการณ์ที่เซิร์ฟเวอร์แบบ self-hosted ต้องพบเจออยู่ตลอดเวลา Reverse proxy ของคุณจะสอบถามไปยัง SSO server ว่าคำขอนั้นได้รับอนุญาตหรือไม่ก่อนที่จะส่งต่อไปยังบริการปลายทาง (upstream) แอปที่อยู่เบื้องหลังจะไม่รับรู้เรื่อง SSO เลย มันจะได้รับเฉพาะคำขอที่ proxy ตรวจสอบเรียบร้อยแล้ว โดยมักจะระบุชื่อผู้ใช้มาใน header

Proxy provider ของ authentik รองรับการทำงานนี้ผ่าน 3 โหมดที่มีเอกสารกำกับไว้ โหมด "Proxy" จะให้ authentik outpost ส่ง traffic ไปยังแอปปลายทางโดยตรง โหมด "Forward auth (single application)" จะให้ traffic คงอยู่ที่ reverse proxy เดิมของคุณและใช้ authentik เฉพาะการตรวจสอบสิทธิ์เท่านั้น ส่วนโหมด "Forward auth (domain level)" จะปกป้องทุกแอปภายใต้โดเมนหลักด้วย provider เดียวกัน โหมด domain level เป็นโหมดที่สะดวกที่สุดแต่มีข้อจำกัดที่ระบุไว้ชัดเจนคือ "ไม่สามารถบังคับใช้กฎการอนุญาตระดับแอปพลิเคชันที่แตกต่างกันสำหรับแต่ละแอปที่ได้รับการปกป้องได้" ดังนั้นทุกแอปภายใต้โดเมนนั้นจึงต้องใช้ชุดนโยบายเดียวกัน

Keycloak ไม่มีฟีเจอร์นี้เลย Proxy คู่หูของมันอย่าง Keycloak Gatekeeper ถูกเปลี่ยนชื่อเป็น Louketo Proxy และถูกเก็บถาวร (archive) บน GitHub ไปแล้ว โดย commit ล่าสุดเกิดขึ้นในเดือนสิงหาคม 2023 หากต้องการปกป้องแอปที่ไม่มีการรองรับ OIDC คุณต้องรันคอมโพเนนต์แยกต่างหากไว้ด้านหน้า ซึ่งมักจะเป็น oauth2-proxy โดยชี้ไปยัง Keycloak client ส่วน Zitadel เองก็ไม่มีโหมด forward auth ในตัวเช่นกัน ดังนั้นคำตอบจึงเป็นการติดตั้งคอมโพเนนต์เสริมเพื่อดูแล ตรวจสอบ และอัปเกรดเพิ่มอีกหนึ่งตัว

การเพิ่มขั้นตอนดังกล่าวเป็นจุดที่การตั้งค่า reverse proxy เริ่มซับซ้อนขึ้น ดังนั้นโปรดอ่าน วิธีที่ Traefik ทำหน้าที่เป็นหน้าด่านให้กับแอป Docker Compose หลายตัว ก่อนที่จะเชื่อมต่อ auth middleware เข้าไปในระบบ

เส้นทางการอัปเกรดมีความยุ่งยากเพียงใด

ณ เดือนสิงหาคม 2026 เวอร์ชันปัจจุบันคือ Keycloak 26.7.1, authentik 2026.5.6 และ Zitadel v4.16.3 ทั้งสามซอฟต์แวร์มีการทำ schema migration กับ PostgreSQL ซึ่งหมายความว่าการอัปเกรดทุกครั้งคือการเปลี่ยนแปลงฐานข้อมูล คุณต้องสำรองข้อมูลฐานข้อมูลก่อนเสมอในทุกครั้ง นิสัยนี้มีค่ามากกว่าฟีเจอร์ใดๆ ในการเปรียบเทียบนี้

authentik มีกฎที่เข้มงวดที่สุดและระบุไว้อย่างชัดเจนว่า "การอัปเกรดต้องเป็นไปตามลำดับของรุ่นหลัก (major release) ห้ามข้ามจากเวอร์ชันหลักรุ่นเก่าไปยังเวอร์ชันล่าสุดโดยตรง" คุณต้องอัปเกรดไปยังแพตช์ล่าสุดของแต่ละเวอร์ชันก่อนที่จะขยับไปยังเวอร์ชันถัดไป และ "authentik ไม่รองรับการดาวน์เกรด" การปล่อยให้โครงการที่ใช้การระบุเวอร์ชันตามปฏิทินล้าหลังไปหนึ่งปี จะทำให้การอัปเกรดครั้งเดียวกลายเป็นภาระที่ต้องทำต่อเนื่องกันหลายครั้ง ซึ่งแต่ละครั้งจะมีขั้นตอนการย้ายฐานข้อมูลของตัวเอง

คู่มือการอัปเกรดของ Keycloak กำหนดลำดับขั้นตอนที่ต้องปฏิบัติตาม ได้แก่ ตรวจสอบการเปลี่ยนแปลงการย้ายข้อมูลจากเวอร์ชันก่อนหน้า อัปเกรดเซิร์ฟเวอร์ จากนั้นจึงอัปเกรดอะแดปเตอร์ การย้ายฐานข้อมูลจะทำงานโดยอัตโนมัติ หรือคุณสามารถส่งออก (export) และนำไปใช้ด้วยตนเองได้ ซึ่งมีประโยชน์เมื่อคุณต้องการตรวจสอบการเปลี่ยนแปลงก่อนที่จะมีการปรับใช้จริง ต้นทุนที่ต้องจ่ายสำหรับ Keycloak คือการอ่านบันทึกการเปลี่ยนแปลง เนื่องจากบันทึกประจำรุ่น (release notes) มักระบุถึงฟีเจอร์ที่ถูกยกเลิก (deprecations) และการเปลี่ยนแปลงพฤติกรรมของระบบ ซึ่งหากมองข้ามไปอาจนำไปสู่ปัญหาที่มีค่าใช้จ่ายสูงได้

Zitadel แยกขั้นตอนการเริ่มต้น (init) และการตั้งค่า (setup) ออกจากการทำงานของเซิร์ฟเวอร์ โดยคำแนะนำสำหรับการใช้งานจริงแนะนำให้แยกส่วนเหล่านี้ออกจากกันเพื่อไม่ให้การขยายระบบ (scaling) ต้องทำขั้นตอนการตั้งค่าซ้ำ สำหรับการใช้งานบน VPS เดียวกันนั้น หมายความว่าขั้นตอนการตั้งค่าต้องเสร็จสิ้นก่อนที่ API จะรายงานสถานะว่าพร้อมใช้งาน (healthy) ซึ่งเป็นเหตุผลว่าทำไมไฟล์ compose จึงมาพร้อมกับ health checks และคำสั่งเริ่มต้นที่ใช้ --wait

กลุ่มเป้าหมายของแต่ละโปรเจกต์และจุดที่แต่ละตัวเสียเปรียบ

Keycloak คือ identity server ของ Red Hat ซึ่งสร้างมาเพื่อองค์กรที่มีการจัดการ realm, กลุ่ม, การจับคู่บทบาท (role mapping) และมี corporate directory อยู่เดิม นี่คือการนำมาตรฐานไปใช้งานที่สมบูรณ์ที่สุดในบรรดาทั้งสามตัว แต่จะเสียเปรียบเมื่อนำไปรันบน VPS ขนาด 2 GB ที่มีแอป self-hosted สี่ตัว ซึ่งครึ่งหนึ่งไม่มีการรองรับ OIDC คุณต้องเสีย RAM ถึง 1250 MB ให้กับ JVM ต้องเรียนรู้โมเดล realm ที่ออกแบบมาเพื่อบริษัท และยังต้องติดตั้ง oauth2-proxy เพิ่มสำหรับแอปที่คุณต้องการใช้งานจริง

authentik ถูกสร้างมาเพื่อกลุ่มผู้ใช้งานแบบ self-hosting โดยเฉพาะ ซึ่งเห็นได้ชัดจากรายการฟีเจอร์ มันมาพร้อมกับ forward auth และ LDAP provider รวมถึงสามารถสร้างขั้นตอนการล็อกอินผ่านตัวแก้ไขแบบ visual ได้ แต่จะเสียเปรียบเมื่อคุณต้องการสัญญาการสนับสนุนจากผู้จำหน่าย (vendor support) หรือรอบการปล่อยอัปเดต (release train) ที่ไม่มีการเปลี่ยนแปลงบ่อยทุกสองสามสัปดาห์ การใช้เลขเวอร์ชันตามปฏิทิน (calendar versioning) โดยไม่มีเส้นทางการ downgrade และไม่สามารถข้ามเวอร์ชันได้นั้นสร้างภาระในการดูแลระบบจริง และตัวแก้ไข flow ก็เป็นโมเดลใหม่ที่ต้องเรียนรู้ ทั้งที่ปัญหาจริงของคุณอาจมีแค่การเชื่อมต่อ OIDC client เพียงตัวเดียว

Zitadel ถูกสร้างมาเพื่อนักพัฒนาที่ต้องการฝังระบบยืนยันตัวตนไว้ในผลิตภัณฑ์ที่ตนเองพัฒนา โดยมี API ที่แข็งแกร่งและรองรับ multi-tenancy เป็นฟีเจอร์หลัก แต่จะเสียเปรียบในกรณีนี้โดยเฉพาะ ด้วยการใช้คอนเทนเนอร์สี่ตัว, ไม่มี forward auth และฐานข้อมูลที่ต้องใช้ขนาด 4 GB ต่อคอร์ ซึ่งเป็นสัดส่วนที่ไม่เหมาะสมสำหรับ VPS หนึ่งเครื่องที่มีเพียงโปรแกรมจัดการรหัสผ่านและวิกิรันอยู่เบื้องหลัง

สิ่งที่ผมจะรันบน VPS หนึ่งเครื่อง และวิธีการดำเนินการ

สำหรับ VPS หนึ่งเครื่องที่มีแอปพลิเคชันแบบ self-hosted สามหรือสี่แอป ให้รัน authentik ทั้งสามตัวเลือกมีหน้าจอสำหรับเข้าสู่ระบบเหมือนกัน แต่ปัจจัยตัดสินใจคือแอปบางตัวของคุณอาจไม่รองรับ OIDC ซึ่ง authentik แก้ปัญหานี้ด้วยฟีเจอร์ forward auth ที่รวมมาให้ในตัว แทนที่จะต้องติดตั้งคอมโพเนนต์อื่นเพิ่ม

หากทำได้ให้จัดสรร RAM ขนาด 4 GB และใช้ 2 GB เฉพาะในกรณีที่แอปที่รันควบคู่กันมีขนาดเล็กเท่านั้น อย่าเปิดพอร์ต 9000 สู่สาธารณะ และให้ทำ TLS termination ที่ reverse proxy ซึ่งวางอยู่ด้านหน้า ให้ทำการสำรองข้อมูล PostgreSQL ทุกคืนและจัดเก็บไว้นอกเครื่อง เพราะผู้ให้บริการยืนยันตัวตนที่ไม่มีการสำรองข้อมูลถือเป็นจุดบกพร่องจุดเดียว (single point of failure) ของทุกแอปที่อยู่เบื้องหลัง ให้รัน stack นี้ด้วยบัญชีผู้ใช้ที่ไม่มีสิทธิ์พิเศษ (unprivileged account) แทนการใช้ root โดยเนื้อหาใน การตั้งค่าผู้ใช้ที่มีสิทธิ์น้อยที่สุดบน VPS จะครอบคลุมถึงการจัดการบัญชีและการเป็นเจ้าของไฟล์ที่จำเป็นสำหรับเรื่องนี้

ให้เลือกใช้ Keycloak แทนเมื่อแอปทุกตัวที่คุณต้องการปกป้องรองรับ OIDC หรือ SAML อยู่แล้ว หรือเมื่อคุณต้องการโมเดลบทบาทที่ละเอียดซึ่ง Keycloak realms มอบให้ได้ เลือกใช้ Zitadel เมื่อคุณกำลังสร้างแอปพลิเคชันเพื่อให้ผู้อื่นเข้ามาสมัครใช้งาน และคุณต้องการ API รวมถึงโมเดลผู้เช่า (tenant model) ของมัน ทั้งสองตัวเลือกนี้ไม่ใช่กรณีการใช้งานแอปสามตัวบนเครื่องเดียวตามที่บทความนี้กล่าวถึง

รูปแบบความล้มเหลวที่คุณจะพบเป็นอันดับแรก

Keycloak ไม่มีข้อมูลหลังจากรีสตาร์ท คุณเริ่มการทำงานด้วย start-dev ซึ่งใช้ฐานข้อมูลสำหรับการพัฒนาในเครื่อง ในคอนเทนเนอร์ที่ไม่มีการทำ volume การลบคอนเทนเนอร์จะทำให้ realm หายไป ให้เปลี่ยนไปใช้ start โดยชี้ KC_DB=postgres ไปยังฐานข้อมูลจริง

คอนเทนเนอร์ worker ของ authentik หายไปบนเครื่องขนาดเล็ก ทั้ง worker และ server ใช้ image เดียวกันและรันกระบวนการ Python ทั้งคู่ ในขณะที่ PostgreSQL ต้องการทรัพยากรส่วนแบ่งจากโฮสต์ที่มี RAM 2 GB ให้รัน docker compose ps เพื่อยืนยันว่าบริการใดหยุดทำงาน จากนั้นตรวจสอบ dmesg เพื่อดูว่ามีการสั่ง kill เนื่องจากหน่วยความจำไม่พอ (out-of-memory) หรือไม่ ก่อนที่จะไปไล่หาบั๊กในตัวแอป

Console ของ Zitadel ไม่ทำงานเมื่ออยู่หลัง proxy ของคุณ Zitadel API ใช้ gRPC ซึ่งต้องการการเชื่อมต่อแบบ HTTP/2 ไปจนถึง upstream หน้าข้อกำหนดของระบบระบุว่าต้องการ reverse proxy ที่รองรับการเชื่อมต่อ upstream แบบ HTTP/2 และได้ระบุเวอร์ชันที่ผ่านการทดสอบแล้วของ Traefik v3.x, NGINX v1.x, Caddy v2.x และ Apache httpd 2.4.x หาก proxy ลดระดับการเชื่อมต่อ upstream ลงเป็น HTTP/1.1 คุณจะพบว่าหน้าล็อกอินโหลดได้ แต่ Console จะทำงานล้มเหลว

ทุกแอปส่งคุณกลับไปยังหน้าล็อกอิน URL สาธารณะของเซิร์ฟเวอร์ SSO และ URL ที่ตั้งค่าไว้ในแอปต้องตรงกันทุกประการ รวมถึง scheme และพอร์ต Keycloak เรียกสิ่งนี้ว่าการตั้งค่า hostname ส่วน Zitadel เรียกว่า external domain เมื่อค่าเหล่านี้ไม่ตรงกัน แอปจะเปลี่ยนเส้นทางไปยังหน้าล็อกอินที่เซิร์ฟเวอร์ไม่รู้จักว่าเป็นของตนเอง และเบราว์เซอร์จะวนลูปไปมาระหว่างสองหน้านี้

FAQ

ตัวเลือกใดใน 3 ตัวนี้ที่เหมาะกับ VPS ขนาด 2 GB?

authentik และ Keycloak โดย authentik ระบุความต้องการขั้นต่ำไว้ที่ CPU 2 คอร์และ RAM 2 GB ส่วนคู่มือการปรับขนาดของ Keycloak ระบุว่าต้องใช้หน่วยความจำพื้นฐาน 1250 MB สำหรับตัวเซิร์ฟเวอร์ก่อนจะนับรวมฐานข้อมูล ทั้งสองตัวนี้จะทำงานได้ค่อนข้างจำกัดบน RAM 2 GB เมื่อคุณเพิ่มแอปพลิเคชันที่คุณต้องการปกป้องเข้าไป ดังนั้นควรพิจารณา RAM 4 GB เป็นระดับที่เหมาะสมสำหรับการใช้งานจริง ส่วน Zitadel ระบุไว้ที่ 2 GB สำหรับการรันครั้งแรก แต่คำแนะนำสำหรับการใช้งานจริง (production) ต้องการ CPU 4 คอร์สำหรับการทำ password hashing และ RAM 4 GB ต่อคอร์ของฐานข้อมูล ดังนั้น 2 GB จึงไม่ใช่ขนาดที่เพียงพอสำหรับการใช้งานจริง

Keycloak หรือ Zitadel สามารถปกป้องแอปที่ไม่มีระบบล็อกอินในตัวได้หรือไม่?

ไม่ได้ด้วยตัวมันเอง ทั้งสองตัวไม่มีคอมโพเนนต์สำหรับทำ forward auth มาให้ ส่วน Louketo Proxy ซึ่งเป็นพร็อกซีคู่หูเดิมของ Keycloak นั้นถูกเก็บถาวร (archived) บน GitHub ไปแล้วโดยมีการ commit ครั้งล่าสุดในเดือนสิงหาคม 2023 จึงไม่ควรนำมาใช้เป็นพื้นฐานในการพัฒนา คุณต้องใช้ oauth2-proxy หรือคอมโพเนนต์ที่คล้ายกันวางไว้ระหว่าง reverse proxy กับแอปพลิเคชันของคุณ แล้วชี้ไปยัง OIDC client บนเซิร์ฟเวอร์ SSO สำหรับ authentik นั้นสามารถทำสิ่งนี้ได้โดยตรงผ่าน proxy provider ในโหมด "Forward auth (single application)" หรือ "Forward auth (domain level)"

ตัวใดสามารถทำหน้าที่เป็น LDAP server สำหรับแอปที่รองรับเฉพาะ LDAP ได้?

authentik โดย LDAP provider ของมันจะทำงานบน outpost และทำให้ผู้ใช้และกลุ่มใน authentik สามารถค้นหาผ่าน LDAP ได้ โดยรองรับ LDAPS บนพอร์ต 636 ซึ่งเป็นแบบอ่านอย่างเดียว (read-only) ดังนั้นการ bind และ search จึงใช้งานได้ แต่การเขียนข้อมูล (writes) จะทำไม่ได้ ส่วน Keycloak และ Zitadel จะทำงานในทิศทางตรงกันข้าม คือทั้งคู่จะอ่านข้อมูลจาก LDAP directory ที่มีอยู่เดิมเพื่อใช้เป็นแหล่งข้อมูลผู้ใช้ และไม่มีตัวใดที่ตอบรับการทำ LDAP bind จากแอปพลิเคชันภายนอก

ฉันสามารถข้ามเวอร์ชันตอนอัปเกรด authentik ได้หรือไม่?

ไม่ได้ เอกสารระบุว่าการอัปเกรดต้องทำตามลำดับของ major release และคุณไม่ควรข้ามจากเวอร์ชันหลักที่เก่ากว่าไปยังเวอร์ชันล่าสุดโดยตรง ให้ย้ายไปยัง patch release ล่าสุดของแต่ละเวอร์ชันก่อน จากนั้นจึงค่อยๆ อัปเกรดขึ้นไปทีละเวอร์ชัน ให้สำรองข้อมูล PostgreSQL ก่อนเริ่มแต่ละขั้นตอนเสมอ เพราะ authentik ไม่รองรับการย้อนกลับ (downgrade) และการทำ migration จะทำงานไปข้างหน้าเท่านั้น