ZITADEL مقابل Keycloak مقابل Authentik: أيهما تختار لتطبيق B2B SaaS
Keycloak هو المعيار التاريخي، غني بالميزات ومدعوم من Red Hat. مشكلته على VPS المستضاف ذاتياً: JVM. في حالة الخمول، يستهلك Keycloak بين 512 ميغابايت و1 غيغابايت من الذاكرة.
Authentik (2026.8.2) هو الاختيار الطبيعي للفرق التي تريد IdP كاملاً مع واجهة رسومية وتدفقات بصرية. مكتوب بـ Python/Django ويتطلب ما لا يقل عن 1 غيغابايت من الذاكرة العاملة.
ZITADEL (v2.x، Go) هو الوحيد من بين الثلاثة الذي صمّم تعدد المستأجرين كبنية أولية من الدرجة الأولى. تنشئ المؤسسات المستقلة في تثبيت واحد — لكل عميل مساحته المعزولة تماماً.
لماذا يتميز ZITADEL للاستخدام في الوكالات و B2B SaaS
- تعدد المستأجرين الأصلي: المؤسسات والمشاريع بنى أولية في نموذج البيانات، وليست حلولاً مؤقتة
- مكتوب بـ Go: ثنائي واحد، يبدأ في ثوانٍ، بصمة ذاكرة من 150 إلى 300 ميغابايت
- OIDC وOAuth2 وSAML 2.0 وLDAP: جميع بروتوكولات المؤسسات في تثبيت واحد
- Passkeys وWebAuthn أصليان منذ v2: يمكن لكل مؤسسة فرض استخدام Passkeys كعامل مصادقة وحيد
- API-أولاً بـ gRPC/REST: كل عملية متاحة في وحدة التحكم متاحة أيضاً عبر واجهة برمجية
- إجراءات (webhooks/كود): منطق مخصص يُشغَّل عند أحداث المصادقة دون تعديل النواة
- نشر بدون حالة تطبيقية: ZITADEL يخزن كل شيء في PostgreSQL — لا ذاكرة تخزين مؤقتة موزعة
- رخصة Apache 2.0: النواة مفتوحة المصدر بالكامل
المتطلبات الأساسية: الخادم وDocker وDNS
الحد الأدنى الموصى به للإنتاج هو 2 vCPU و4 غيغابايت من الذاكرة العشوائية — منها حوالي 300 ميغابايت تستخدمها ZITADEL نفسها، والباقي يذهب إلى PostgreSQL وخدمات أخرى.
البرامج المطلوبة: Docker Engine 24+ وDocker Compose v2. يجب أن تكون المنافذ 80 و443 مفتوحة (nginx سيتولى إنهاء TLS). اسم نطاق يشير إلى IP الخاص بـ VPS الخاص بك.
قاعدة البيانات: PostgreSQL 15 أو 16. يدعم ZITADEL أيضاً CockroachDB لعمليات النشر عالية التوافر، لكن على عقدة واحدة VPS، يُعدّ PostgreSQL الاختيار الطبيعي.
نشر ZITADEL باستخدام Docker Compose وPostgreSQL
إنشاء هيكل مجلد العمل
اتصل بـ VPS الخاص بك عبر SSH وأنشئ المجلدات اللازمة:
mkdir -p /opt/zitadel/{config,certs} cd /opt/zitadelإنشاء ملف .env مع الأسرار
توليد أسرار قوية:
cat > /opt/zitadel/.env <<EOF POSTGRES_PASSWORD=$(openssl rand -base64 32 | tr -d '\n') ZITADEL_MASTERKEY=$(openssl rand -base64 32 | tr -d '\n' | head -c 32) ZITADEL_DOMAIN=sso.your-domain.com EOFكتابة ملف docker-compose.yml
أنشئ /opt/zitadel/docker-compose.yml بخدمتي PostgreSQL وZITADEL، وقم بتكوين اتصال قاعدة البيانات عبر متغيرات البيئة وعرض المنفذ 8080 لـ nginx.
تكوين nginx كـ reverse proxy مع TLS
أنشئ كتلة خادم nginx لـ sso.your-domain.com تعيد توجيه HTTP إلى HTTPS وتوكل الطلبات إلى http://127.0.0.1:8080. احصل على شهادة Let's Encrypt مع Certbot.
تشغيل حزمة ZITADEL
cd /opt/zitadel docker compose up -d docker compose logs -f zitadelانتظر ظهور
server is listening on [::]:8080 في السجلات.استرداد بيانات اعتماد المسؤول الأولية
docker compose logs zitadel 2>&1 | grep -A 5 'initial'تظهر بيانات الاعتماد مرة واحدة فقط في السجلات. دوّنها في مدير الأسرار الخاص بك.
تسجيل الدخول إلى وحدة تحكم الإدارة
افتح
https://sso.your-domain.com/ui/console في متصفحك. سجل الدخول ببيانات الاعتماد المسترجعة.إنشاء أول مؤسسة عميل
في وحدة التحكم، انتقل إلى المؤسسة ← مؤسسة جديدة. أعطها اسم عميلك. ينشئ ZITADEL تلقائياً مساحة معزولة.
إنشاء مشروع وتطبيق OIDC
في المؤسسة، انتقل إلى المشاريع ← مشروع جديد. أنشئ تطبيق ويب من نوع OIDC. سيولّد ZITADEL معرّف العميل والسر.
التحقق من الصحة وتثبيت إصدار الصورة
curl -s https://sso.your-domain.com/healthz | jq .استجابة
{"status": "pass"} تؤكد أن ZITADEL يستجيب بشكل صحيح.
تكوين مصادقة OIDC لتطبيقاتك
بمجرد تشغيل ZITADEL وإنشاء تطبيق OIDC، يكون الإعداد من جانب العميل معيارياً — أي مكتبة OIDC تعمل دون تكيف خاص بـ ZITADEL.
المعاملات الأساسية:
ISSUER=https://sso.your-domain.com
CLIENT_ID=<معرف_العميل_المولّد>
CLIENT_SECRET=<سر_العميل_المولّد>
REDIRECT_URI=https://your-app.com/callback
SCOPES=openid profile emailمستند الاكتشاف متاح على https://sso.your-domain.com/.well-known/openid-configuration. بالنسبة لتطبيقات SPA، استخدم تدفق PKCE بدون سر جانب العميل.
نموذج متعدد المستأجرين: المؤسسات والمشاريع والتطبيقات
نموذج بيانات ZITADEL منظم في ثلاثة مستويات تتوافق تماماً مع احتياجات الوكالة أو B2B SaaS.
المؤسسة هي حاوية المستأجر. لكل مؤسسة مستخدموها الخاصون، ومزودو الهوية الخارجيون وسياسات كلمة المرور الخاصة بها.
المشروع يجمع تطبيقات منتج واحد. يمكن أن يحتوي المشروع على تطبيق ويب وتطبيق جوال وواجهة برمجية — جميعها تشترك في نفس الأدوار والأذونات.
التطبيق يمثل عميل OIDC أو OAuth2 أو SAML محدداً. يُمكّن هذا النموذج وكالةً من إدارة عشرة عملاء على تثبيت ZITADEL واحد دون أي خطر تلوث بين المستأجرين.
ZITADEL مقابل Authentik مقابل Keycloak — مقارنة تقنية
مرّر الجدول أفقيًا
| المعيار | ZITADEL v2.x | Authentik 2026.8 | Keycloak 26.7 |
|---|---|---|---|
| اللغة / بيئة التشغيل | Go — ثنائي واحد | Python + Rust (واجهة أمامية) | Java (JVM) |
| ذاكرة الحزمة الكاملة (خمول) | 150 – 300 ميغابايت | ~1 غيغابايت | 512 ميغابايت – 1 غيغابايت |
| تعدد المستأجرين الأصلي | نعم — بنية المؤسسات الأولية | جزئي — مستأجرون منفصلون | جزئي — realms منفصلة |
| OIDC / OAuth2 / SAML | نعم — الثلاثة أصليان | نعم — الثلاثة أصليان | نعم — الثلاثة أصليان |
| Passkeys / WebAuthn | نعم، أصلي v2 | نعم (2026.2+) | نعم (v21+) |
| API أولاً | gRPC + REST، تغطية 100% | REST جزئي | REST جزئي |
| واجهة الإدارة | وحدة تحكم ويب + API | واجهة كاملة مع تدفقات بصرية | واجهة كاملة، إعداد XML |
| الرخصة | Apache 2.0 (النواة) | MIT / Enterprise | Apache 2.0 |
تفعيل Passkeys والمصادقة متعددة العوامل في ZITADEL v2
يقدم ZITADEL v2 Passkeys WebAuthn كعامل مصادقة أساسي. لتفعيلها في مؤسسة:
1. افتح المؤسسة ← سياسة الأمان ← سياسة MFA
2. فعّل Passkeys وحدد إلزامي إذا أردت أن يستخدم جميع المستخدمين Passkeys فقط
3. لسياسة أكثر مرونة: اسمح بـ Passkeys وـ TOTP معاً — يختار المستخدم عند التسجيل
ZITADEL يدعم أيضاً TOTP المعياري (Google Authenticator، أي تطبيق متوافق مع RFC 6238) ومفاتيح الأمان المادية U2F/FIDO2 (YubiKey، إلخ).
استكشاف الأخطاء: الأخطاء الشائعة مع ZITADEL تحت Docker
masterkey must be 32 characters: استخدم openssl rand -hex 16 (32 حرفاً سداسياً = 16 بايت) للحصول على مفتاح بطول صحيح.
connection refused على المنفذ 8080 والحاوية تعمل: ZITADEL لا يستجيب إلا بعد اكتمال الترحيلات — انتظر server is listening on [::]:8080 في السجلات.
حلقة إعادة التوجيه HTTP/HTTPS: تأكد أن proxy_set_header X-Forwarded-Proto https موجود في كتلة location / بـ nginx.
invalid_client أثناء تدفق OIDC: تأكد أن عنوان URL لإعادة التوجيه يتطابق تماماً مع ما هو مُعلن في تطبيق ZITADEL.
بيانات اعتماد المسؤول مفقودة: احذف قاعدة البيانات (docker compose down -v) وأعد تشغيل start-from-init. في الإنتاج، أنشئ حساب مسؤول ثانياً فوراً.
الخطوة التالية: تعمّق في مكدس SSO المستضاف ذاتياً
ZITADEL في الإنتاج على VPS هو خطوة أولى ممتازة. للتعمق أكثر:
- [نشر ZITADEL على VPS — دليل متقدم](/deployer-zitadel-vps): شهادات TLS تلقائية مع Let's Encrypt، نسخ احتياطي لـ PostgreSQL إلى S3.
- [Authentik مقابل Authelia](/authentik-vs-authelia-sso-self-hosted): المقارنة بين أخف البدائل.
- [الانتقال من Keycloak](/keycloak-cves-semaine-38-migrer-authelia-zitadel-vps): تحليل الثغرات الست للأسبوع 38 ومسار الانتقال الفعلي.
- [استضافة Authelia على VPS](/self-host-authelia-vps): إذا كنت تبحث عن بوابة مصادقة خفيفة جداً.
