مقایسه Keycloak و authentik و Zitadel برای یک VPS

کدام سرور SSO برای یک VPS مناسب است

Keycloak، authentik و Zitadel سرورهای Single Sign-On (SSO) خودمیزبانی هستند که هر زمان صحبت از داشتن یک ورود واحد برای تمام برنامه‌های روی سرور می‌شود، مطرح می‌گردند. این گزینه‌ها روی یک VPS کوچک با هم قابل جایگزینی نیستند. authentik گزینه پیش‌فرض امن برای سروری است که 3 یا 4 برنامه خودمیزبان را اجرا می‌کند، زیرا تنها گزینه از این سه مورد است که می‌تواند یک صفحه ورود را جلوی برنامه‌ای که خودش سیستم ورود ندارد، قرار دهد. 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
  }
]

صفحه نصب Docker Compose برای authentik درخواست «میزبانی با حداقل 2 هسته CPU و 2 گیگابایت RAM» را دارد که معادل 2048 مگابایت است و فایل compose منتشرشده برای آن، 3 کانتینر را اجرا می‌کند: PostgreSQL، سرور و worker.

Keycloak دقیق‌ترین رقم را در میان 3 مورد ارائه می‌دهد. راهنمای تعیین اندازه آن بیان می‌کند که «میزان مصرف پایه حافظه برای یک Pod، شامل کش داده‌های Realm و 10,000 نشست کش‌شده، 1250 مگابایت RAM است». این 1250 مگابایت تنها مربوط به پردازش Java است و دیتابیس را شامل نمی‌شود. همان صفحه توضیح می‌دهد که چرا محدودیت کانتینر بسیار اهمیت دارد: Keycloak حدود 70 درصد از محدودیت حافظه را به عنوان heap در نظر می‌گیرد و علاوه بر آن، حدود 300 مگابایت حافظه غیر-heap مصرف می‌کند. اگر به کانتینر 1 گیگابایت حافظه اختصاص دهید، حدود 717 مگابایت را به عنوان heap محاسبه می‌کند، در حالی که همچنان به آن 300 مگابایت حافظه غیر-heap نیاز دارد؛ بنابراین پیش از آنکه حتی داده‌های نشست در کش قرار بگیرند، محدودیت حافظه به پایان رسیده است.

صفحه compose برای Zitadel نیز درخواست 2 گیگابایت، یعنی همان 2048 مگابایت را دارد، اما این رقم برای اولین اجرا است. صفحه مربوط به محیط production همان جایی است که باید مطالعه کنید. خودِ پردازش Zitadel به «تقریباً 512 مگابایت RAM نیاز دارد و می‌تواند با کمتر از یک هسته CPU کار کند». بخش پرهزینه، دیتابیس است: «حدود یک هسته CPU به ازای هر 100 درخواست در ثانیه (req/s) و 4 گیگابایت RAM به ازای هر هسته». هش کردن رمز عبور نیز به «4 هسته CPU در دسترس برای این منظور» نیاز دارد، زیرا جهش در تعداد ورودها منجر به افزایش ناگهانی مصرف CPU می‌شود. فایل compose رسمی نسخه v4، تعداد 4 کانتینر را پیش از افزودن هر چیز دیگری اجرا می‌کند: Traefik به عنوان پروکسی، API مربوط به Zitadel، یک کانتینر جداگانه برای رابط کاربری ورود (Login UI) و PostgreSQL. سرویس‌های Redis و جمع‌آوری‌کننده OpenTelemetry در پروفایل‌های اختیاری compose قرار دارند.

بنابراین Keycloak و authentik روی یک VPS با 4 گیگابایت RAM به همراه فضای کافی برای برنامه‌هایی که محافظت می‌کنید، جای می‌گیرند. Zitadel با 2 گیگابایت بالا می‌آید، اما در هر ورود کاربر، برای حافظه با PostgreSQL خود رقابت خواهد کرد. من Zitadel را با کمتر از 4 گیگابایت RAM اجرا نمی‌کنم و روی سروری که میزبان برنامه‌های دیگر نیز هست، 8 گیگابایت را ترجیح می‌دهم.

هر کدام در سیستم شما دقیقاً چه چیزی را اجرا می‌کنند

authentik شامل یک پایگاه داده PostgreSQL و دو نسخه از یک image، یعنی یک server و یک worker است. بخش server به درخواست‌های 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

بخش server پورت‌های 9000 و 9443 را منتشر می‌کند. اولین بازدید از پورت 9000، جریان راه‌اندازی اولیه را اجرا می‌کند که در آن رمز عبور کاربر پیش‌فرض یعنی akadmin را تعیین می‌کنید. پیش از آنکه این پورت از طریق اینترنت در دسترس قرار گیرد، حتماً یک reverse proxy با یک گواهی معتبر در مقابل آن قرار دهید.

Keycloak شامل یک پردازش واحد به همراه پایگاه داده‌ای است که شما فراهم می‌کنید. نسخه quickstart آن یک 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 (امنیت لایه انتقال) اجرا می‌شود، بنابراین containerای که به این روش شروع شده و بعداً حذف شود، realm شما را نیز با خود از بین می‌برد. محیط عملیاتی (Production) به معنای استفاده از start است، که از طریق KC_DB به یک PostgreSQL واقعی متصل شده و از طریق KC_HOSTNAME دارای یک نام دامنه عمومی است. راهنمای عملیاتی Keycloak همچنین تأکید می‌کند که تمام ارتباطات از و به سرور نیازمند یک کانال امن است، بنابراین در آنجا HTTPS اختیاری نیست.

Zitadel همان پشته چهار-containerای است که در بالا توضیح داده شد.

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 برای رمزنگاری داده‌های حساس در پایگاه داده استفاده می‌کند، بنابراین از دست دادن آن به معنای از دست دادن دسترسی به آن داده‌ها است. اگر در اجرای چنین پشته‌هایی تازه‌کار هستید، اصول Docker Compose برای VPS گزینه‌های مربوط به volume و سیاست‌های restart را پوشش می‌دهد که تعیین می‌کنند آیا سرویس احراز هویت شما پس از reboot زنده می‌ماند یا خیر.

هر کدام از چه پروتکل‌هایی پشتیبانی می‌کنند؟

هر سه ابزار از OpenID Connect (OIDC) پشتیبانی می‌کنند؛ لایه ورود به سیستم بر پایه OAuth 2.0 که برنامه‌های مدرن از آن استفاده می‌کنند. همچنین هر سه از SAML 2.0 (زبان نشانه‌گذاری تأیید امنیتی) پشتیبانی می‌کنند؛ استانداردی قدیمی‌تر که نرم‌افزارهای سازمانی همچنان آن را عرضه می‌کنند. تفاوت اصلی در LDAP (پروتکل سبک دسترسی به دایرکتوری) است، جایی که یک واژه دو کارکرد متضاد را پوشش می‌دهد.

خواندن از LDAP به این معناست که سرور SSO گذرواژه‌ها را با دایرکتوری‌ای که از قبل اجرا کرده‌اید، تطبیق می‌دهد. Keycloak این کار را از طریق user federation انجام می‌دهد. Zitadel نیز همین قابلیت را دارد: مستندات آن توضیح می‌دهد که چگونه «یک سرور LDAP را به عنوان یک identity provider در ZITADEL متصل کنید».

ارائه سرویس LDAP به این معناست که برنامه‌ای که فقط از LDAP پشتیبانی می‌کند، می‌تواند به سرور SSO شما متصل (bind) شود، گویی که آن سرور همان دایرکتوری است. فقط authentik این کار را انجام می‌دهد. ارائه‌دهنده LDAP در این ابزار، «تمام کاربران و گروه‌ها در پایگاه داده authentik را از طریق یک LDAP outpost اختصاصی، در دایرکتوری LDAP قابل جستجو می‌کند» که LDAPS آن روی پورت 636 در دسترس است. این سرویس فقط‌خواندنی (read-only) است، بنابراین عملیات bind و search کار می‌کنند اما عملیات نوشتن خیر. یک کد یک‌بارمصرف با استفاده از علامت سمیکولن به گذرواژه اضافه می‌شود، همان‌طور که در password;123456 آمده است، و احراز هویت پیامکی (SMS) در حین عملیات bind پشتیبانی نمی‌شود.

اگر یکی از برنامه‌های موجود در لیست شما فقط از LDAP پشتیبانی می‌کند، مقایسه در همین‌جا به پایان می‌رسد. Keycloak و Zitadel نمی‌توانند به آن درخواست bind پاسخ دهند، بنابراین باید یک دایرکتوری دوم در کنار آن‌ها اجرا کنید و دو لیست کاربری را با هم همگام (sync) نگه دارید.

در مورد برنامه‌هایی که اصلاً سیستم ورود ندارند چه باید کرد؟

پاسخ این مسئله Forward auth است؛ سناریویی که در یک سرور self-hosted دائماً با آن مواجه می‌شوید. در این حالت، reverse proxy پیش از ارسال درخواست به سرویس مقصد (upstream)، از سرور SSO می‌پرسد که آیا این درخواست مجاز است یا خیر. برنامهٔ پشتِ پروکسی هیچ اطلاعی از SSO ندارد. این برنامه درخواست‌هایی را دریافت می‌کند که قبلاً توسط پروکسی بررسی شده‌اند؛ معمولاً نام کاربری در قالب یک header به برنامه ارسال می‌شود.

ارائه‌دهندهٔ Proxy در authentik این قابلیت را در سه حالت مستندشده پوشش می‌دهد. حالت "Proxy" باعث می‌شود outpost مربوط به authentik ترافیک را مستقیماً به برنامهٔ upstream ارسال کند. حالت "Forward auth (single application)" ترافیک را در اختیار reverse proxy فعلی شما باقی می‌گذارد و از authentik فقط برای بررسی احراز هویت استفاده می‌کند. حالت "Forward auth (domain level)" تمامی برنامه‌های زیرمجموعهٔ یک دامنهٔ والد را با یک ارائه‌دهنده محافظت می‌کند. حالت Domain level راحت‌ترین گزینه است اما یک محدودیت مستندشده دارد: این حالت «نمی‌تواند قوانین مجوزدهی (authorization) متفاوتی را برای هر برنامهٔ محافظت‌شده اعمال کند»، بنابراین تمام برنامه‌های تحت آن دامنه از یک مجموعه سیاست مشترک استفاده می‌کنند.

Keycloak هیچ‌کدام از این قابلیت‌ها را ندارد. پروکسی همراه آن یعنی Keycloak Gatekeeper به Louketo Proxy تغییر نام داد و سپس در GitHub آرشیو شد؛ آخرین commit آن مربوط به اوت 2023 است. برای محافظت از برنامه‌ای که از OIDC پشتیبانی نمی‌کند، باید یک مؤلفهٔ جداگانه در مقابل آن اجرا کنید که معمولاً oauth2-proxy است و به یک کلاینت Keycloak اشاره می‌کند. Zitadel نیز حالت Forward auth اختصاصی ندارد، بنابراین پاسخ در آنجا هم استفاده از همان مؤلفهٔ اضافی است که باید نصب، مانیتور و به‌روزرسانی شود.

این گام اضافی همان جایی است که پیکربندی reverse proxy از سادگی خارج می‌شود؛ بنابراین پیش از متصل کردن یک middleware احراز هویت، نحوه قرارگیری Traefik در مقابل چندین برنامه Docker Compose را مطالعه کنید.

مسیر ارتقا چقدر دشوار است؟

تا اوت 2026، نسخه‌های فعلی Keycloak 26.7.1، authentik 2026.5.6 و Zitadel v4.16.3 هستند. هر سه مورد، مهاجرت‌های شمای دیتابیس را روی PostgreSQL اجرا می‌کنند، به این معنی که هر ارتقا یک تغییر در دیتابیس است. همیشه و در هر بار ارتقا، از دیتابیس نسخه پشتیبان تهیه کنید. این عادت، ارزشمندتر از هر قابلیت دیگری در این مقایسه است.

نرم‌افزار authentik سخت‌گیرانه‌ترین قانون را دارد و آن را به‌صراحت بیان می‌کند: «ارتقاها باید به ترتیب نسخه‌های اصلی (major releases) انجام شوند؛ مستقیماً از یک نسخه اصلی قدیمی به جدیدترین نسخه نپرید.» شما باید پیش از رفتن به نسخه بعدی، ابتدا به آخرین پچ در هر نسخه برسید؛ همچنین «authentik از دانگرید (بازگشت به نسخه قبلی) پشتیبانی نمی‌کند». عقب ماندن به مدت یک سال در پروژه‌ای که از نسخه‌گذاری تقویمی استفاده می‌کند، یک ارتقای ساده را به زنجیره‌ای از ارتقاها تبدیل می‌کند که هر کدام مهاجرت دیتابیس خاص خود را دارند.

راهنمای ارتقای Keycloak ترتیبی را برای دنبال کردن ارائه می‌دهد: تغییرات مهاجرت نسخه قبلی را بررسی کنید، سرور را ارتقا دهید و سپس آداپتورها را به‌روزرسانی کنید. مهاجرت دیتابیس به‌صورت خودکار اجرا می‌شود، یا می‌توانید آن را export کرده و به‌صورت دستی اعمال کنید؛ این کار زمانی مفید است که بخواهید پیش از اعمال تغییرات، آن‌ها را مطالعه کنید. هزینه کار با Keycloak همین مطالعه است. یادداشت‌های انتشار آن شامل موارد منسوخ‌شده (deprecations) و تغییرات رفتاری است که نادیده گرفتن آن‌ها آسان و هزینه‌بر است.

نرم‌افزار Zitadel مراحل init و setup را از سرور در حال اجرا جدا می‌کند و راهنمای تولید (production) آن توصیه می‌کند که این مراحل جدا نگه داشته شوند تا مقیاس‌پذیری باعث تکرار کارهای setup نشود. روی یک VPS تکی، این یعنی مرحله setup باید پیش از آنکه API وضعیت سالم (healthy) را گزارش کند، به پایان برسد؛ به همین دلیل فایل compose شامل health check است و دستور شروع از --wait استفاده می‌کند.

مخاطبان هدف هر پروژه و نقاط ضعف آن‌ها

Keycloak سرور هویت شرکت Red Hat است که برای سازمان‌هایی با قابلیت تعریف قلمرو (realm)، گروه‌ها، نگاشت نقش‌ها و دایرکتوری‌های شرکتی موجود طراحی شده است. این ابزار کامل‌ترین پیاده‌سازی استانداردها را در میان این سه گزینه دارد. نقطه ضعف آن در یک VPS با ظرفیت 2 GB رم است که چهار سرویس self-hosted روی آن اجرا می‌شود و نیمی از آن‌ها از OIDC پشتیبانی نمی‌کنند. شما باید 1250 MB رم را صرف JVM کنید، مدل قلمرویی را که برای یک شرکت طراحی شده بیاموزید و در نهایت همچنان مجبورید برای سرویس‌هایی که واقعاً به آن‌ها اهمیت می‌دهید، oauth2-proxy نصب کنید.

authentik برای مخاطبان self-hosting ساخته شده و لیست قابلیت‌های آن گویای همین موضوع است. این ابزار دارای قابلیت forward auth و فراهم‌کننده LDAP است و جریان‌های ورود (login flows) را در یک ویرایشگر بصری می‌سازد. نقطه ضعف آن زمانی است که به قرارداد پشتیبانی شرکتی یا چرخه‌ای از نسخه‌ها (release train) نیاز دارید که هر چند هفته یک‌بار تغییر نکند. نسخه‌گذاری تقویمی (Calendar versioning) بدون مسیر دانگرید و بدون امکان پرش از نسخه‌ها، بار عملیاتی واقعی ایجاد می‌کند و ویرایشگر جریان (flow editor) یک مدل کامل برای یادگیری است، در حالی که مشکل اصلی شما صرفاً یک کلاینت OIDC است.

Zitadel برای توسعه‌دهندگانی ساخته شده که احراز هویت را درون محصولی که عرضه می‌کنند قرار می‌دهند؛ این ابزار دارای API قدرتمند و قابلیت چندمستأجری (multi-tenancy) به عنوان ویژگی‌های اصلی است. نقطه ضعف آن دقیقاً در همین سناریو است. چهار کانتینر، عدم وجود forward auth و دیتابیسی با حجم 4 GB به ازای هر هسته، ساختار نامناسبی برای یک VPS است که تنها یک مدیریت‌کننده رمز عبور و یک ویکی را میزبانی می‌کند.

چه چیزی را روی یک VPS اجرا کنم و چگونه

برای یک VPS با سه یا چهار سرویس self-hosted، از authentik استفاده کنید. هر سه گزینه یک صفحه ورود در اختیار شما قرار می‌دهند. عامل تعیین‌کننده این است که برخی از برنامه‌های شما هرگز از OIDC پشتیبانی نمی‌کنند و authentik این مشکل را با قابلیت forward auth که به‌صورت داخلی در خود دارد، حل می‌کند؛ بدون اینکه نیاز به افزودن مؤلفه دیگری در کنار آن باشد.

اگر امکان دارد 4 GB رم به آن اختصاص دهید و تنها در صورتی که برنامه‌های جانبی کوچک هستند، از 2 GB استفاده کنید. پورت 9000 را از دسترس اینترنت عمومی خارج کنید و TLS را در یک reverse proxy که در لایه جلویی قرار دارد، terminate کنید. به‌صورت شبانه از PostgreSQL نسخه پشتیبان (dump) تهیه کرده و آن را خارج از سرور ذخیره کنید، زیرا یک سرویس احراز هویت بدون پشتیبان، نقطه شکست واحد برای تمام برنامه‌های پشت آن است. این پشته (stack) را با یک حساب کاربری اختصاصی و بدون دسترسی root اجرا کنید: تنظیم کاربران با حداقل دسترسی روی یک VPS جزئیات مربوط به حساب کاربری و مالکیت فایل‌های مورد نیاز را پوشش می‌دهد.

زمانی Keycloak را انتخاب کنید که تمام برنامه‌های تحت حفاظت شما از قبل از OIDC یا SAML پشتیبانی می‌کنند، یا زمانی که به مدل نقش‌های دقیق (fine-grained) که realms در Keycloak ارائه می‌دهد نیاز دارید. زمانی Zitadel را انتخاب کنید که در حال توسعه برنامه‌ای برای ثبت‌نام دیگران هستید و به API و مدل tenant آن نیاز دارید. هیچ‌کدام از این دو مورد، سناریوی سه-برنامه-روی-یک-سرور که این مطلب به آن می‌پردازد، نیستند.

حالت‌های شکستی که در ابتدا با آن‌ها مواجه می‌شوید

Keycloak پس از راه‌اندازی مجدد هیچ داده‌ای ندارد. شما آن را با start-dev اجرا کرده‌اید که از یک پایگاه‌داده محلی برای توسعه استفاده می‌کند. در کانتینری که فاقد volume است، حذف کانتینر باعث حذف realm می‌شود. به سراغ start بروید و KC_DB=postgres را به یک پایگاه‌داده واقعی متصل کنید.

کانتینر worker مربوط به authentik در سرورهای کوچک ناپدید می‌شود. worker و server از یک image یکسان استفاده می‌کنند و هر دو پردازش‌های Python را اجرا می‌کنند؛ در حالی که PostgreSQL نیز سهم خود را از 2 GB حافظه میزبان می‌خواهد. دستور docker compose ps را اجرا کنید تا مشخص شود کدام سرویس خارج شده است، سپس پیش از آنکه به دنبال باگ در برنامه بگردید، dmesg را برای بررسی احتمال کشته شدن پردازش توسط OOM (کمبود حافظه) چک کنید.

کنسول Zitadel پشت پروکسی شما کار نمی‌کند. 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 را نام می‌برد. پروکسی‌ای که اتصال upstream را به HTTP/1.1 تنزل دهد، باعث می‌شود صفحه ورود بارگذاری شود اما کنسول با خطا مواجه گردد.

هر برنامه شما را به صفحه ورود بازمی‌گرداند. URL عمومی سرور SSO و URL پیکربندی‌شده در برنامه باید دقیقاً یکسان باشند، که شامل طرح (scheme) و پورت نیز می‌شود. Keycloak این مورد را تنظیمات hostname می‌نامد و Zitadel آن را دامنه خارجی (external domain) می‌خواند. زمانی که این دو با هم مطابقت نداشته باشند، برنامه به صفحه‌ای برای ورود هدایت می‌کند که سرور آن را متعلق به خود نمی‌داند و مرورگر بین این دو مدام جابه‌جا می‌شود.

FAQ

کدام‌یک از این سه مورد برای یک VPS با 2 گیگابایت رم مناسب است؟

authentik و Keycloak. حداقل نیاز اعلام‌شده برای authentik، میزبانی با 2 هسته CPU و 2 گیگابایت رم است و راهنمای تعیین اندازه Keycloak، حافظه پایه مورد نیاز برای سرور (پیش از احتساب دیتابیس) را 1250 مگابایت تعیین کرده است. هر دو گزینه در صورت اضافه کردن برنامه‌هایی که قصد محافظت از آن‌ها را دارید، در 2 گیگابایت رم با محدودیت مواجه می‌شوند؛ بنابراین 4 گیگابایت رم را به عنوان حداقلِ مطلوب در نظر بگیرید. Zitadel برای اولین اجرا 2 گیگابایت رم را پیشنهاد می‌دهد، اما راهنمای عملیاتی آن برای هش کردن رمز عبور به 4 هسته CPU و برای هر هسته دیتابیس به 4 گیگابایت رم نیاز دارد؛ بنابراین 2 گیگابایت برای یک استقرار واقعی کافی نیست.

آیا Keycloak یا Zitadel می‌توانند از برنامه‌ای که سیستم ورود اختصاصی ندارد، محافظت کنند؟

به تنهایی خیر. هیچ‌کدام از آن‌ها مؤلفه forward auth داخلی ندارند. پروکسی قدیمی 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 آن روی یک outpost اجرا می‌شود و کاربران و گروه‌های موجود در authentik را از طریق LDAP قابل جستجو می‌کند؛ همچنین LDAPS روی پورت 636 در دسترس است. این قابلیت فقط خواندنی (read-only) است، بنابراین عملیات bind و search کار می‌کنند اما امکان نوشتن وجود ندارد. Keycloak و Zitadel در جهت عکس عمل می‌کنند: هر دو از یک دایرکتوری LDAP موجود به عنوان منبع کاربر می‌خوانند و هیچ‌کدام به درخواست LDAP bind از سمت یک برنامه پاسخ نمی‌دهند.

آیا می‌توانم هنگام ارتقای authentik، نسخه‌ها را نادیده بگیرم (skip کنم)؟

خیر. مستندات تأکید می‌کنند که ارتقا باید طبق توالی نسخه‌های اصلی (major releases) انجام شود و نباید مستقیماً از یک نسخه اصلی قدیمی به جدیدترین نسخه جهش کرد. ابتدا به آخرین نسخه patch در هر نسخه اصلی بروید و سپس مرحله به مرحله ارتقا دهید. پیش از هر مرحله از PostgreSQL نسخه پشتیبان تهیه کنید، زیرا authentik از دانگرید (downgrade) پشتیبانی نمی‌کند و migrationها فقط رو به جلو اجرا می‌شوند.