Keycloak מול authentik מול Zitadel: השוואת שרתי SSO ל-VPS

איזה שרת SSO מתאים ל-VPS יחיד

Keycloak, authentik ו-Zitadel הם שרתי Single Sign-On (SSO) בניהול עצמי שעולים לדיון בכל פעם שמישהו מעוניין בחיבור יחיד לכל היישומים בשרת שלו. ב-VPS קטן, הם אינם ניתנים להחלפה. authentik הוא ברירת המחדל הבטוחה עבור שרת שמריץ שלושה או ארבעה יישומים בניהול עצמי, כיוון שהוא היחיד מבין השלושה שיכול להציב מסך התחברות לפני יישום שאין לו מנגנון כניסה משלו. Keycloak הוא הבחירה הנכונה כאשר כל יישום שאתם מאבטחים כבר תומך בפרוטוקול סטנדרטי, וביכולתכם להקצות זיכרון עבור Java virtual machine (JVM). Zitadel נבנה עבור מפתחים שמפיצים מוצר דרך API, והוא השירות שלא הייתי מנסה להריץ תחת 4 GB של זיכרון.

בחרו תחילה, ורק אז התקינו. לאחר שבחרתם, המדריך המעשי להתקנת authentik על VPS מכסה את תהליך ההגדרה צעד אחר צעד.

כמה RAM כל אחד מהם באמת צריך?

התחילו בבדיקת רף המשאבים המינימלי, שכן הוא קובע את הרשימה הסופית עוד לפני בחינת תכונות. המספרים להלן הם הנתונים הרשמיים שפורסמו על ידי כל פרויקט, נכון לאוגוסט 2026. מדובר בהנחיות ספק, ולא בתוצאות של בדיקות עומסים.

[
  {
    "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
  }
]

דף ההתקנה של authentik ב-Docker Compose דורש "מארח עם לפחות 2 ליבות CPU ו-2 GB של RAM", כלומר 2048 MB, וקובץ ה-compose שפורסם מריץ 3 מכולות: PostgreSQL, השרת, וה-worker.

Keycloak מפרסם את הנתון הספציפי ביותר מבין ה-3. מדריך הגודל שלו מציין כי "צריכת הזיכרון הבסיסית עבור Pod, כולל מטמונים של נתוני Realm ו-10,000 סשנים במטמון, היא 1250 MB של RAM". אותם 1250 MB מכסים את תהליך ה-Java בלבד, עוד לפני מסד הנתונים. אותו דף מסביר מדוע מגבלת המכולה כה קריטית: Keycloak מקצה 70% ממגבלת הזיכרון ל-heap ומשתמש בערך ב-300 MB של זיכרון non-heap מעבר לכך. אם תקצו למכולה 1 GB, היא תחשב heap של כ-717 MB בעוד שהיא עדיין זקוקה לאותם 300 MB של זיכרון non-heap, כך שהמגבלה מנוצלת במלואה עוד לפני שנתוני סשן כלשהם נכנסים למטמון.

דף ה-compose של Zitadel דורש גם הוא 2 GB, אותם 2048 MB, אך נתון זה מתייחס להרצה ראשונית בלבד. יש לעיין בדף ה-production. תהליך ה-Zitadel עצמו זקוק ל-"כ-512MB של RAM ויכול לפעול עם פחות מליבת CPU אחת". מסד הנתונים הוא החלק היקר: "בערך ליבת CPU אחת לכל 100 בקשות בשנייה (req/s) ו-4GB של RAM לכל ליבה". תהליך ה-hashing של סיסמאות דורש לאחר מכן "4 ליבות CPU זמינות למטרה זו", כיוון שפרץ של התחברויות מתרגם לזינוק ב-CPU. קובץ ה-compose הרשמי בגרסה v4 מריץ 4 מכולות לפני שמוסיפים דבר: Traefik כ-proxy, ה-API של Zitadel, מכולת ממשק התחברות (Login UI) נפרדת, ו-PostgreSQL. Redis ואוסף OpenTelemetry נמצאים מאחורי פרופילי compose אופציונליים.

לסיכום, Keycloak ו-authentik יכולים לעבוד על VPS של 4 GB עם מקום פנוי עבור היישומים שאתם מאבטחים. Zitadel יתחיל על 2 GB, אך יתחרה על הזיכרון מול ה-PostgreSQL שלו בכל התחברות. לא הייתי מריץ את Zitadel על פחות מ-4 GB, ובשרת שמארח גם יישומים אחרים, הייתי ממליץ על 8 GB.

מה כל אחד מהם מריץ בפועל על השרת שלך

authentik מורכב מ-PostgreSQL ושני עותקים של אותו image, שרת ו-worker. השרת עונה לבקשות HTTP ומכיל outpost מוטמע. ה-worker מריץ משימות רקע כגון סנכרון ספריות ושליחת דוא"ל. ההתקנה המפורסמת קצרה.

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

השרת מפרסם את פורטים 9000 ו-9443. הביקור הראשון בפורט 9000 מפעיל את תהליך ההגדרה הראשוני, שבו קובעים את הסיסמה עבור משתמש ה-akadmin המוגדר כברירת מחדל. יש להציב reverse proxy עם תעודה אמיתית לפניו, לפני שפורט זה יהיה נגיש מהאינטרנט.

Keycloak הוא תהליך אחד בתוספת מסד נתונים שאתה מספק. ההתקנה המהירה היא מכולה (container) בודדת.

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 (אבטחת שכבת תעבורה), לכן מכולה שהופעלה כך והוסרה לאחר מכן תיקח איתה את ה-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 שקובעות האם ספק הזהות שלך ישרוד אתחול.

באילו פרוטוקולים תומך כל אחד מהם?

כל השלושה תומכים ב-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 כספק זהות ב-ZITADEL".

הגשת LDAP משמעותה שיישום שתומך ב-LDAP בלבד יכול לבצע bind מול שרת ה-SSO שלכם כאילו היה ספריית משתמשים. רק authentik עושה זאת. ספק ה-LDAP שלו הופך את "כל המשתמשים והקבוצות במסד הנתונים של authentik לניתנים לחיפוש דרך ספריית ה-LDAP" באמצעות LDAP outpost ייעודי, כאשר LDAPS זמין בפורט 636. השירות הוא לקריאה בלבד, לכן פעולות bind וחיפוש עובדות, אך כתיבה אינה נתמכת. קוד חד-פעמי מתווסף לסיסמה עם נקודה-פסיק, כפי שמופיע ב-password;123456, ואימות באמצעות SMS אינו נתמך במהלך ה-bind.

אם אחד היישומים ברשימה שלכם תומך ב-LDAP בלבד, ההשוואה מסתיימת כאן. Keycloak ו-Zitadel אינם יכולים להשיב לבקשת ה-bind הזו, ולכן תצטרכו להריץ ספרייה שנייה לצדם ולסנכרן בין שתי רשימות משתמשים.

מה לגבי יישומים שאין להם מנגנון התחברות כלל?

הפתרון הוא Forward auth, וזהו תרחיש ששרתים בניהול עצמי נתקלים בו ללא הרף. ה-reverse proxy שלכם שואל את שרת ה-SSO האם הבקשה מורשית לפני שהוא מעביר אותה ל-upstream. היישום שמאחורי ה-proxy אינו מודע ל-SSO. הוא מקבל בקשות שה-proxy כבר אימת, בדרך כלל עם שם המשתמש בתוך header.

ספק ה-proxy של authentik מכסה זאת בשלושה מצבים מתועדים. מצב "Proxy" גורם ל-outpost של authentik להעביר את התעבורה ליישום ה-upstream בעצמו. מצב "Forward auth (single application)" משאיר את התעבורה ב-reverse proxy הקיים שלכם ומשתמש ב-authentik רק לצורך בדיקת האימות. מצב "Forward auth (domain level)" מגן על כל יישום תחת דומיין אב אחד באמצעות ספק יחיד. רמת הדומיין היא הנוחה ביותר, אך יש לה מגבלה מתועדת: היא "אינה יכולה לאכוף חוקי הרשאה שונים ברמת היישום עבור כל יישום מוגן", לכן כל היישומים תחת אותו דומיין חולקים סט מדיניות אחד.

ל-Keycloak אין יכולות כאלו. ה-proxy הנלווה שלו, Keycloak Gatekeeper, שונה שמו ל-Louketo Proxy ולאחר מכן הועבר לארכיון ב-GitHub, כאשר ה-commit האחרון שלו בוצע באוגוסט 2023. כדי להגן על יישום ללא תמיכת OIDC, מריצים רכיב נפרד לפניו, בדרך כלל oauth2-proxy, המופנה ל-client של Keycloak. גם ל-Zitadel אין מצב Forward auth משלו, לכן התשובה במקרה זה היא אותו רכיב נוסף שיש להתקין, לנטר ולעדכן.

אותו דילוג נוסף הוא הנקודה שבה התצורה של ה-reverse proxy מפסיקה להיות פשוטה, לכן קראו את כיצד Traefik משמש כחזית למספר יישומי Docker Compose לפני שאתם מחברים אליו middleware של אימות.

עד כמה מסלול השדרוג בעייתי?

נכון לאוגוסט 2026, הגרסאות העדכניות הן Keycloak 26.7.1, authentik 2026.5.6 ו-Zitadel v4.16.3. כל השלוש מריצות מיגרציות של סכימה מול PostgreSQL, מה שאומר שכל שדרוג הוא שינוי במסד הנתונים. בצעו גיבוי למסד הנתונים לפני כל פעולה, בכל פעם. הרגל זה שווה יותר מכל תכונה בהשוואה זו.

ל-authentik יש את הכלל המחמיר ביותר והוא מצהיר עליו בבירור: "שדרוגים חייבים לעקוב אחר רצף הגרסאות הראשיות; אין לדלג ישירות מגרסה ראשית ישנה לגרסה העדכנית ביותר". עליכם לעבור לגרסת התיקון (patch) האחרונה בתוך כל גרסה לפני המעבר לגרסה הבאה, ו-"authentik אינה תומכת בביצוע downgrade". פיגור של שנה בפרויקט המשתמש בגרסאות מבוססות תאריך הופך שדרוג בודד לשרשרת של שדרוגים, כאשר לכל אחד מהם מיגרציית מסד נתונים משלו.

מדריך השדרוג של Keycloak מציג סדר פעולות שיש לעקוב אחריו: סקירת שינויי המיגרציה מהגרסה הקודמת, שדרוג השרת, ולאחר מכן שדרוג ה-adapters. מיגרציית מסד הנתונים מתבצעת אוטומטית, או שניתן לייצא אותה ולהחיל אותה ידנית, דבר שימושי כאשר רוצים לקרוא את השינוי לפני שהוא מוחל. המחיר ב-Keycloak הוא הקריאה הזו. הערות השחרור שלו כוללות הוצאה משימוש של תכונות (deprecations) ושינויי התנהגות שקל לפספס ויקר להתעלם מהם.

Zitadel מפרידה בין שלבי ה-init וה-setup לבין השרת הפעיל, והנחיות ה-production שלה ממליצות להשאיר אותם מופרדים כדי שפעולות scaling לא יחזרו על עבודת ההתקנה. ב-VPS בודד, המשמעות היא ששלב ה-setup חייב להסתיים לפני שה-API מדווח על תקינות (healthy), וזו הסיבה שקובץ ה-compose כולל בדיקות תקינות (health checks) ופקודת ההפעלה משתמשת ב---wait.

קהל היעד של כל פרויקט והמקרים שבהם הוא אינו מתאים

Keycloak הוא שרת הזהויות של Red Hat, שנבנה עבור ארגונים עם realms, קבוצות, מיפוי תפקידים וספריית משתמשים ארגונית קיימת. זהו המימוש המלא ביותר של תקנים מבין השלושה. הוא אינו מתאים לשרת VPS עם 2 GB RAM שמריץ ארבעה יישומים בניהול עצמי, כאשר מחציתם אינם תומכים ב-OIDC. אתם משלמים 1250 MB עבור ה-JVM, לומדים מודל של realm שתוכנן עבור חברה, ועדיין נדרשים להתקין oauth2-proxy עבור היישומים שבאמת עניינו אתכם.

authentik נבנה עבור קהל המשתמשים שמנהל שירותים בעצמו, ורשימת התכונות משקפת זאת. הוא כולל forward auth וספק LDAP, ומאפשר לבנות תהליכי התחברות בעורך ויזואלי. הוא אינו מתאים כאשר אתם זקוקים לחוזה תמיכה מספק או למחזור גרסאות (release train) שאינו משתנה בכל כמה שבועות. שימוש בגרסאות מבוססות תאריך ללא נתיב לשנמוך (downgrade) וללא אפשרות לדלג על גרסאות מייצר עבודה תפעולית ממשית, ועורך התהליכים הוא מודל שלם שצריך ללמוד כאשר הבעיה האמיתית שלכם היא בסך הכל לקוח OIDC אחד.

Zitadel נבנה עבור מפתחים המטמיעים אימות בתוך מוצר שהם מפיצים, עם API חזק וריבוי דיירים (multi-tenancy) כתכונות ליבה. הוא אינו מתאים בדיוק במקרה הזה. ארבעה קונטיינרים, ללא forward auth, ומסד נתונים שדורש 4 GB לכל ליבה הם תצורה שגויה עבור שרת VPS בודד שמריץ מנהל סיסמאות ו-wiki.

מה להריץ על VPS יחיד וכיצד

עבור שרת VPS יחיד המארח שלושה או ארבעה יישומים, השתמשו ב-authentik. כל השלושה מספקים מסך התחברות. הגורם המכריע הוא שחלק מהיישומים שלכם לא יתמכו ב-OIDC, ו-authentik פותר זאת באמצעות forward auth מובנה, ללא צורך ברכיב נוסף לצדו.

הקצו ל-authentik זיכרון של 4 GB אם ניתן, או 2 GB בלבד אם היישומים האחרים קטנים. אל תחשפו את פורט 9000 לאינטרנט הציבורי ובצעו TLS termination ב-reverse proxy שנמצא לפניו. בצעו גיבויים ליליים של PostgreSQL ושמרו אותם מחוץ לשרת, שכן ספק זהות ללא גיבוי מהווה נקודת כשל יחידה עבור כל היישומים שמאחוריו. הריצו את ה-stack תחת משתמש ייעודי ללא הרשאות root; המדריך הגדרת משתמשים עם הרשאות מינימליות ב-VPS מפרט את ניהול המשתמש והבעלות על הקבצים הנדרשים לכך.

בחרו ב-Keycloak כאשר כל היישומים שאתם מאבטחים כבר תומכים ב-OIDC או ב-SAML, או כאשר אתם זקוקים למודל תפקידים מפורט כפי ש-Keycloak realms מציעים. בחרו ב-Zitadel כאשר אתם בונים יישום המיועד להרשמת משתמשים חיצוניים ואתם זקוקים ל-API ולמודל ה-tenant שלו. אף אחת מהאפשרויות הללו אינה מתאימה למקרה של שלושה יישומים על שרת יחיד, שהוא נושא פוסט זה.

מצבי כשל נפוצים שתיתקל בהם בתחילה

ל-Keycloak אין נתונים לאחר אתחול. הפעלת אותו עם start-dev, המשתמש במסד נתונים מקומי לפיתוח. במכולה ללא volume, הסרת המכולה מוחקת את ה-realm. עברו ל-start עם KC_DB=postgres המוגדר להצביע על מסד נתונים אמיתי.

מכולת ה-worker של authentik נעלמת בשרת קטן. ה-worker והשרת מריצים את אותה תמונה ושניהם מריצים תהליכי Python, בעוד ש-PostgreSQL דורש את חלקו בשרת עם 2 GB זיכרון. הריצו docker compose ps כדי לוודא איזה שירות קרס, ולאחר מכן בדקו את dmesg עבור אירוע out-of-memory kill לפני שתחפשו באג ביישום.

ה-Console של Zitadel לא עובד מאחורי ה-proxy שלך. ה-API של Zitadel משתמש ב-gRPC, הדורש HTTP/2 לכל אורך הדרך עד ל-upstream. דף הדרישות מציין צורך ב-reverse proxy התומך בחיבורי HTTP/2 ל-upstream, ומפרט גרסאות שנבדקו של 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. כאשר הם אינם תואמים, היישום מבצע הפניה (redirect) להתחברות שהשרת אינו מזהה כשלו, והדפדפן יקפוץ הלוך ושוב בין השניים.

FAQ

איזו מבין השלוש מתאימה ל-VPS עם 2 GB RAM?

authentik ו-Keycloak. הדרישה המוצהרת של authentik היא מארח עם לפחות 2 ליבות CPU ו-2 GB RAM, ומדריך הגודל של Keycloak מציין צריכת זיכרון בסיסית של 1250 MB עבור השרת לפני מסד הנתונים. שתי המערכות יהיו דחוקות ב-2 GB ברגע שתוסיפו את היישומים שאתם מאבטחים, לכן כדאי להתייחס ל-4 GB כרף המינימלי הנוח. Zitadel מפרסמת דרישה של 2 GB להרצה ראשונית, אך הנחיות הייצור שלה ממליצות על 4 ליבות CPU עבור גיבוב סיסמאות ו-4 GB RAM לכל ליבת מסד נתונים, כך ש-2 GB אינם מהווים פריסה מעשית.

האם Keycloak או Zitadel יכולות לאבטח יישום שאין לו מנגנון התחברות משלו?

לא באופן עצמאי. אף אחת מהן לא כוללת רכיב forward auth. ה-proxy המלווה הישן של Keycloak, ה-Louketo Proxy, נמצא בארכיון ב-GitHub וה-commit האחרון שלו הוא מאוגוסט 2023, לכן אין להסתמך עליו. עליכם להציב את oauth2-proxy או רכיב דומה בין ה-reverse proxy לבין היישום, ולהפנות אותו ללקוח OIDC בשרת ה-SSO. המערכת authentik מבצעת זאת באופן טבעי באמצעות ה-proxy provider שלה במצב "Forward auth (single application)" או "Forward auth (domain level)".

איזו מהן יכולה לשמש כשרת LDAP עבור יישום שתומך ב-LDAP בלבד?

authentik. ה-LDAP provider שלה רץ על outpost והופך משתמשים וקבוצות ב-authentik לניתנים לחיפוש דרך LDAP, עם תמיכה ב-LDAPS בפורט 636. השירות הוא לקריאה בלבד, כך שפעולות bind וחיפוש עובדות, אך כתיבה אינה נתמכת. Keycloak ו-Zitadel פועלות בכיוון ההפוך: שתיהן קוראות מספריית LDAP קיימת כמקור משתמשים, ואף אחת מהן אינה מגיבה ל-LDAP bind מצד יישום.

האם ניתן לדלג על גרסאות בעת שדרוג authentik?

לא. התיעוד מציין ששדרוגים חייבים להתבצע לפי סדר גרסאות ה-major, ואין לדלג מגרסת major ישנה ישירות לגרסה העדכנית ביותר. עברו תחילה לגרסת ה-patch האחרונה בכל גרסה, ולאחר מכן התקדמו גרסה אחת בכל פעם. בצעו גיבוי ל-PostgreSQL לפני כל שלב, כיוון ש-authentik אינה תומכת ב-downgrade וה-migrations רצות קדימה בלבד.