Authentik أم ZITADEL أم Keycloak: أي حل SSO مستضاف ذاتيًا تختار؟

لديك ثماني حاويات Docker تعمل على خادم VPS. Gitea وNextcloud وGrafana وVaultwarden وn8n وPortainer وصفحة حالة وتطبيق داخلي واحد كتبته بنفسك. لكل منها تسجيل دخول خاص. تنسخ كلمات المرور وتلصقها من مدير كلمات المرور كل صباح، وبدأت تتساءل إن كان تسجيل الدخول الموحّد يستحق تكلفته التشغيلية.

في الغالب يستحق. السؤال هو أي موفّر هوية تشغّل.

Keycloak هو الخيار الافتراضي المألوف، لكن الخيار الأنسب يعتمد على شكل حزمتك، وعدد المستخدمين الذين تديرهم، وما إذا كنت تدمج برمجيات تشغّلها بالفعل أم تبني المصادقة داخل تطبيقاتك الخاصة.

تنظر هذه المقارنة بين حلول SSO المستضافة ذاتيًا إلى Authentik وZITADEL وKeycloak وAuthelia من زاوية القرارات التي تهم بعد النشر: دعم البروتوكولات، وإدارة المستخدمين، وسير عمل المطوّر، ومتطلبات الموارد، وما يحدث عندما يتعطل موفّر الهوية.

لماذا يهم SSO المستضاف ذاتيًا

ما إن تعتمد عدة تطبيقات على الأشخاص والمجموعات أنفسهم، تتوقف تسجيلات الدخول المنفصلة عن كونها مريحة. يمنحك موفّر الهوية المستضاف ذاتيًا مكانًا واحدًا لإدارة الحسابات والمصادقة متعددة العوامل وعضوية المجموعات وسياسات الوصول، بدلًا من ضبط هذه الضوابط بشكل مستقل في كل تطبيق.

المقايضة مهمة بالقدر نفسه: يصبح IdP بنية تحتية تعتمد عليها التطبيقات الأخرى. قد تفشل تسجيلات الدخول الجديدة وتجديدات الرموز عندما يكون غير متاح، لذا تصبح النسخ الاحتياطية والوصول للاسترداد والترقيات ووقت التشغيل أهم هنا مما هي عليه في تطبيق مستضاف ذاتيًا عادي.

الخلاصة السريعة

اختر Authentik إذا أردت أفضل خيار افتراضي

لمختبر منزلي أو حزمة أدوات داخلية أو فريق صغير يربط تطبيقات قائمة عبر OIDC أو SAML، يُعد Authentik الخيار الافتراضي الأقوى. سير عمل الإدارة فيه أسهل من Keycloak، ويدعم عدة طرق تكامل، ويبدأ إعداد Docker Compose الرسمي له من نواتي معالج و2 غيغابايت من ذاكرة RAM.

اختر ZITADEL إذا كنت تبني تطبيقات

اختر ZITADEL عندما تكون المصادقة جزءًا من المنتج الذي تبنيه. نموذج المؤسسات فيه، وواجهاته البرمجية، وتعدد المستأجرين، وOIDC، وSAML، ومفاتيح المرور، والمصادقة متعددة العوامل، ودعم موفّري هوية LDAP، كلها منطقية أكثر لفرق تطبيقات SaaS وB2B مما هي لمختبر منزلي نموذجي.

اختر Keycloak إذا احتجت إلى ميزات هوية مؤسسية

اختر Keycloak عندما تحتاج إلى اتحاد أعمق مع LDAP أو Active Directory، أو عدة نطاقات realm، أو سياسات تفويض دقيقة، أو بيئة مبنية أصلًا حول Keycloak. توصي وثائقه بحد ذاكرة قدره 2 غيغابايت لحاويات Keycloak الصغيرة الجاهزة للإنتاج؛ أما خادم VPS الشامل الذي يشغّل PostgreSQL أيضًا فيحتاج إلى هامش إضافي.

خيار بديل: اختر Authelia إذا كنت تحتاج أساسًا إلى جدار تسجيل دخول

اختر Authelia عندما تكون مشكلتك الأساسية حماية التطبيقات عند طبقة الوكيل العكسي بدلًا من تشغيل منصة هوية كاملة. يمكنها أيضًا العمل كموفّر OpenID Connect، لكن المصادقة عند الوكيل العكسي تبقى مركز ثقلها.

ما الذي تتحقق منه قبل اختيار أداة SSO

قبل مقارنة الميزات، قارن كل أداة بالتطبيقات والبروتوكولات ومصادر الهوية التي تحتاج إلى دعمها بالفعل.

كم تطبيقًا يحتاج إلى SSO؟

ابدأ بالتطبيقات لا بموفّر الهوية. حزمة من ستة تطبيقات تدعم OIDC أو SAML بالفعل مشكلة مختلفة عن حزمة من أدوات داخلية قديمة لا تعرف شيئًا عن أي من البروتوكولين. الحالة الأولى تشير إلى IdP كامل. أما الثانية فقد تحتاج إلى مصادقة عند طبقة الوكيل العكسي.

هل تدعم تطبيقاتك OIDC أو SAML؟

OIDC هو الخيار الشائع لتطبيقات الويب الحديثة. ولا يزال SAML مهمًا في برمجيات المؤسسات والتكاملات الأقدم. وقد يهم LDAP عندما يتوقع التطبيق دليلًا بدلًا من تدفق SSO عبر الويب. تحقق مما يقبله كل تطبيق فعليًا قبل اختيار IdP الذي سيتوسط بينها.

هل تدير مستخدمين أم تبني تسجيل الدخول داخل تطبيق؟

إذا كان معظم عملك سيجري في واجهة إدارة بينما تربط تطبيقات قائمة، فإن Authentik هو نقطة البداية الطبيعية. وإذا كانت المصادقة جزءًا من منتج تبنيه وتتوقع إنشاء المؤسسات والمستخدمين والأذونات عبر الكود، فإن ZITADEL أقرب بكثير إلى سير العمل هذا.

هل تحتاج إلى LDAP أو Active Directory أو سياسات متقدمة؟

يمكن لـ Authentik وZITADEL وKeycloak جميعًا الاتصال بمصادر هوية مدعومة بـ LDAP بشكل أو بآخر، لذا لم يعد LDAP وحده يحسم المقارنة. يصبح Keycloak أكثر إثارة للاهتمام عندما يقترن اتحاد الدليل بعدة نطاقات realm، أو مُعيِّنات مفصّلة، أو متطلبات مزامنة، أو سياسات تفويض على مستوى الموارد.

Authentik vs ZITADEL vs Keycloak vs Authelia

تتداخل الأدوات الأربع في SSO، لكنها تتناول الهوية من اتجاهات مختلفة: تكامل التطبيقات، وهوية المنتج، وإدارة الهوية والوصول المؤسسية، والوصول عبر الوكيل العكسي.

Authentik

يشغّل Authentik نشره الأساسي على هيئة خادم وعامل worker وقاعدة بيانات PostgreSQL. لم يعد Redis جزءًا من الحزمة: أزال Authentik هذه التبعية تمامًا في إصدار 2025.10. تتطلب وثائق Docker Compose الحالية مضيفًا بنواتي معالج و2 غيغابايت من ذاكرة RAM على الأقل.

السمة المميزة هي واجهة الإدارة. محرك التدفقات في Authentik، وتوفير التطبيقات، والسياسات القائمة على المجموعات، كلها أسهل تناولًا من نموذج الإعداد الأوسع في Keycloak. إذا سبق لك إعداد تطبيق OIDC في Keycloak ثم قضيت وقتًا تحاول معرفة سبب غياب مطالبات الرمز، فستلاحظ الفرق سريعًا.

يدعم SAML وOAuth2/OIDC وLDAP وRADIUS. وهو الخيار الافتراضي الصحيح لمختبر منزلي أو فريق هندسي صغير يشغّل حزمة من التطبيقات المستضافة ذاتيًا.

ZITADEL

ZITADEL مكتوب أساسًا بلغة Go، ومرخّص بموجب AGPL-3.0، ويقع على خط الإصدارات v4.x. يتضمن النشر واجهة برمجية بلغة Go، وواجهة تسجيل دخول مبنية بـ Next.js، وPostgreSQL، وتدعم المتطلبات الحالية PostgreSQL من الإصدار 14 حتى 18. تتطلب وثائق Docker Compose الرسمية مضيفًا بـ 2 غيغابايت من ذاكرة RAM على الأقل.

السمة المميزة هي الواجهة البرمجية. يكشف ZITADEL سطح هوية كاملًا عبر gRPC وREST، وهو مبني على نموذج متعدد المستأجرين منذ البداية. إذا كنت تبني منتج SaaS وتريد أن تكون طبقة تسجيل الدخول قابلة للبرمجة والأتمتة ومتعددة المستأجرين افتراضيًا، فإن ZITADEL أقرب إلى ما تريده من البدائل.

يدعم OIDC وSAML ومفاتيح المرور والمصادقة متعددة العوامل وموفّري هوية LDAP وواجهة SCIM v2 المصنّفة حاليًا على أنها Preview. نموذج المؤسسات فيه وسير عمله القائم على الواجهة البرمجية أولًا يجعلانه أنسب لفرق المنتجات منه لمختبر منزلي بسيط.

Keycloak

Keycloak منصة لإدارة الهوية والوصول مكتوبة بلغة Java وتعمل على Quarkus. سطح الإعداد فيه أكبر من الخيارات الأخرى هنا، خصوصًا عندما تدخل Realms وClients وRoles واتحاد المستخدمين وAuthorization Services في الصورة.

توصي وثائق الحاويات الرسمية الخاصة به بحد ذاكرة قدره 2 غيغابايت لعمليات النشر الصغيرة الجاهزة للإنتاج. يغطي هذا الرقم حاوية Keycloak نفسها؛ فإذا كان PostgreSQL يشارك خادم VPS نفسه، فامنح المضيف هامشًا أكبر.

سبب قبول هذا التعقيد ملموس. يمكن لـ Keycloak أن يتحد مع أدلة LDAP وActive Directory، ويسجّل أحداث المستخدمين والمسؤولين، ويفرض تفويضًا دقيقًا باستخدام RBAC وABAC وسياسات قائمة على المستخدم وقائمة على السياق وأنواع سياسات أخرى. إذا كنت تحتاج إلى هذه الضوابط، فللإعداد الإضافي غاية.

Authelia

Authelia هي الأصغر بين الأربعة: مرخّصة بموجب Apache 2.0، وملف Go ثنائي واحد، وحاليًا على الإصدار v4.39.x. البنية مختلفة عن الثلاثة الآخرين: تقف Authelia أمام وكيل عكسي (nginx أو Traefik أو Caddy أو HAProxy) وتقرر ما إذا كان يُسمح للطلبات بالوصول إلى الخلفية.

تتضمن Authelia أيضًا موفّر OpenID Connect. لا تزال وثائقها تصف تنفيذ OIDC بأنه نسخة تجريبية مفتوحة، لكن الموفّر حاصل على شهادة OpenID لملفات Basic OP وImplicit OP وHybrid OP وForm Post OP وConfig OP. مجموعة ميزات OIDC فيها أضيق مما يوفره Authentik أو Keycloak لإدارة الهوية، ولهذا تبقى Authelia الأكثر منطقية عندما تكون المصادقة عند الوكيل العكسي هي المهمة الأساسية.

سنعود إلى Authelia في قسم خاص بها. باختصار: مركز ثقل Authelia هو التحكم في الوصول عند الوكيل العكسي، لا إدارة الهوية الكاملة.

مقارنة الميزات

يحصر الجدول أدناه المقارنة في الفروق التي تؤثر في النشر والإدارة اليومية.

أي أداة تناسب أي حزمة؟

يتغير الخيار الأنسب بحسب من يشغّل IdP وكيفية تكامل التطبيقات معه.

الخيار الأفضل لمختبر منزلي

Authentik هو الخيار الافتراضي لمختبر منزلي تدعم فيه معظم التطبيقات OIDC أو SAML بالفعل. يمنحك موفّر هوية كاملًا دون أن يفرض عليك تبني نموذج IAM الأوسع في Keycloak. وإذا كانت معظم الحزمة تحتاج إلى شاشة تسجيل دخول عند الوكيل العكسي بدلًا من SSO أصلي، فقد تكون Authelia الخيار الأبسط.

الخيار الأفضل لحزمة شركة صغيرة

يناسب Authentik معظم حزم التطبيقات الداخلية الصغيرة، خصوصًا عندما يكون الهدف طبقة هوية واحدة لأدوات مثل Grafana وGitea وNextcloud وVaultwarden. ويصبح Keycloak أكثر جاذبية عندما يكون دليل قائم أو عدة نطاقات realm أو سياسات تفويض أعمق جزءًا من المتطلبات.

الخيار الأفضل للمطوّرين ومنتجات SaaS

ZITADEL هو الخيار الأقوى عندما تكون المصادقة جزءًا من المنتج الذي تبنيه. نموذج المؤسسات فيه وتعدد المستأجرين والواجهات البرمجية وسطح الأتمتة أكثر منطقية عندما يلزم إنشاء المستخدمين والمستأجرين من كود التطبيق بدلًا من لوحة الإدارة أساسًا.

اقرأ

أفضل نظام CIAM ذاتي الاستضافة لمطوّري SaaS بنموذج B2B

الخيار الأفضل للفرق المؤسسية أو ذات متطلبات الامتثال الثقيلة

Keycloak منطقي عندما تتضمن قائمة المتطلبات اتحاد دليل معقدًا، وعدة نطاقات realm، وسياسات تفويض مفصّلة، وفريقًا قادرًا على تشغيل تعقيد IAM الإضافي. استضافة Keycloak ذاتيًا لا تجعل البيئة ممتثلة بحد ذاتها؛ فالنسخ الاحتياطية والتوافر والتسجيل ومراجعات الوصول وضوابط التغيير تبقى مسؤولية فريقك.

الخيار الأفضل للتطبيقات التي لا تملك SSO أصليًا

Authelia هي الخيار الأوضح عندما يجب أن تحدث المصادقة قبل وصول الطلبات إلى التطبيق. تعمل جيدًا بشكل خاص مع الوكلاء العكسيين الذين يحمون الأدوات الداخلية القديمة ولوحات المعلومات والخدمات التي لا تدعم OIDC أو SAML بنفسها.

الجزء الصعب في استضافة SSO ذاتيًا

بمجرد أن يصبح SSO إلزاميًا، قد يؤثر خطأ في الإعداد أو فشل في الاسترداد في عدة تطبيقات دفعة واحدة.

التثبيت والإعداد

تشغيل الحاويات ليس سوى الخطوة الأولى. DNS وTLS وعناوين URI لإعادة التوجيه ومطالبات الرموز وتعيينات المجموعات وتسليم البريد الإلكتروني والوصول للاسترداد هي المواضع التي يبدأ فيها نشر SSO بالتحول إلى بنية تحتية بدلًا من مجرد تطبيق Docker آخر.

موارد الخادم

IdP ليس سوى جزء من ميزانية الموارد. يمكن لـ PostgreSQL والوكلاء العكسيين والعمّال workers وتجزئة كلمات المرور والسجلات ومزامنة الدليل أن تتنافس جميعها على المعالج والذاكرة عندما تتشارك خادم VPS واحدًا.

إدارة قاعدة البيانات والنسخ الاحتياطي

يعتمد Authentik وZITADEL وعمليات نشر Keycloak الإنتاجية العادية على قاعدة بيانات. انسخ هذه القاعدة احتياطيًا خارج الخادم، ووثّق كيفية استعادتها، واختبر الاستعادة. نجاح مهمة النسخ الاحتياطي ليس الشيء نفسه كإجراء استرداد يعمل فعلًا.

مخاطر الإغلاق والاسترداد

قد يؤدي عنوان URI خاطئ لإعادة التوجيه، أو سر عميل منتهي الصلاحية، أو اتصال دليل معطّل، أو سياسة صارمة أكثر من اللازم إلى إغلاق الباب أمام المسؤولين مع الجميع. احتفظ بمسار استرداد لا يعتمد على تدفق المصادقة الذي تحاول إصلاحه.

إبقاء IdP متاحًا

لا ينهي تعطل IdP بالضرورة كل جلسات التطبيقات القائمة فورًا. قد تستمر الجلسات القائمة حتى تنتهي صلاحية رموزها أو ملفات تعريف الارتباط الخاصة بها، لكن تسجيلات الدخول الجديدة وتجديدات الرموز قد تفشل. اختبر وضع الفشل هذا قبل أن تجعل SSO إلزاميًا عبر الحزمة كلها.

متى لا ينبغي لك استضافة SSO ذاتيًا

تتوقف الاستضافة الذاتية عن كونها صفقة جيدة عندما يعجز فريقك عن استعادة طبقة الهوية وتشغيلها بالموثوقية التي تتطلبها تطبيقاتك.

متى تكون الهوية المُدارة أكثر أمانًا

تستحق الهوية المُدارة ثمنها عندما تكون تكلفة تشغيل IdP أعلى من التحكم الذي تكسبه باستضافته ذاتيًا. خدمات مثل Auth0 وClerk وWorkOS وMicrosoft Entra ID تنقل الكثير من توافر المنصة والترقيع وصيانة البنية التحتية إلى الموفّر.

تبقى مسؤولًا عن إعداد التطبيقات والأذونات والتخطيط للاسترداد، لكنك لم تعد مسؤولًا عن إبقاء منصة الهوية نفسها متصلة.

متى يعجز فريقك عن تحمّل التوقف

إذا لم يكن في الفريق من يستطيع استعادة IdP، أو إصلاح PostgreSQL، أو استبدال سر منتهي الصلاحية، أو تشخيص اتصال اتحاد فاشل أثناء انقطاع، فقد تكون استضافة الهوية ذاتيًا المقايضة التشغيلية الخاطئة.

الفشل أوسع من تطبيق واحد غير متاح. قد تفشل تسجيلات الدخول الجديدة وتجديدات الرموز عبر عدة تطبيقات في الوقت نفسه.

متى تكون متطلبات الامتثال مرتفعة جدًا

يمكن استخدام الهوية المستضافة ذاتيًا في البيئات الخاضعة للتنظيم، لكن تشغيل البرنامج بنفسك لا ينتج تلقائيًا الضوابط أو الأدلة التي يتوقعها المدقق. يظل فريقك مسؤولًا عن التسجيل ومراجعات الوصول والنسخ الاحتياطية وإدارة التغيير والتوافر والاستجابة للحوادث وأي توثيق يتطلبه الإطار المعمول به.

SSO المستضاف ذاتيًا ليس رمزًا للمكانة. إذا لم يستطع فريقك تشغيل طبقة الهوية بأمان، فقد يكون الدفع مقابل هوية مُدارة القرار الهندسي الأفضل.

أين تساعد Cloudzy

تغيّر Cloudzy طبقة النشر؛ لكنها لا تزيل عمل إعداد الهوية والتشغيل الموصوف أعلاه.

مشكلة نشر SSO يدويًا

يعني نشر SSO يدويًا تجهيز الخادم، وتثبيت التطبيق وقاعدة البيانات، وضبط الوكيل العكسي، وإعداد DNS وTLS، ثم البدء بعد ذلك فقط في إعداد الهوية نفسها. لا شيء من ذلك يغني عن عمل OIDC وSAML والدليل والسياسات الذي يأتي لاحقًا.

نشر SSO بنقرة واحدة على Cloudzy

توفر Cloudzy نشرًا بنقرة واحدة لكل من Authentik وKeycloak. تطبيق Authentik بنقرة واحدة متاح في سوق Cloudzy. تطبيق Keycloak بنقرة واحدة متاح أيضًا في سوق Cloudzy. ZITADEL غير موجود في السوق اليوم، لذا انشره باستخدام إعداد Docker Compose الخاص به على خادم VPS قياسي. يشغّل التثبيت بنقرة واحدة التطبيق الأساسي، بينما يبقى إعداد الهوية وDNS والنسخ الاحتياطية والترقيات والسياسات واختبار الاسترداد تحت سيطرتك.

متى تستخدم خادم VPS منفصلًا لـ IdP

استضافة IdP مع تطبيقاتك أمر معقول لمختبر منزلي يُقبل فيه التوقف. أما في حزمة حرجة للأعمال، فإن فصل موفّر الهوية يزيل نطاق فشل مشتركًا واضحًا: إعادة تشغيل خادم التطبيقات أو استنزافه أو اختراقه لم يعد يعني إسقاط طبقة الهوية معه.

خادم VPS المنفصل ليس مرادفًا للتوافر العالي، لكنه يمنح IdP ميزانية موارد خاصة به، وجدول صيانة خاصًا، وحدود استرداد خاصة.

توصيات تحديد حجم خادم VPS

حدّد حجم الحزمة كاملة لا عملية IdP وحدها، خصوصًا عندما يتشارك PostgreSQL ووكيل عكسي خادم VPS نفسه.

متطلبات Authentik من خادم VPS

تتطلب وثائق Docker Compose الرسمية لـ Authentik مضيفًا بنواتي معالج و2 غيغابايت RAM على الأقل. هذه نقطة البداية الصحيحة لنشر صغير. امنح الخادم هامشًا أكبر عندما يتشارك المضيف نفسه مع PostgreSQL، أو مواقع أمامية outposts إضافية، أو مزامنة الدليل، أو حركة تسجيل دخول أكثف.

متطلبات ZITADEL من خادم VPS

يتطلب نشر ZITADEL الرسمي عبر Docker Compose ما لا يقل عن 2 غيغابايت RAM للمضيف. حدّد حجم خادم VPS شامل لـ ZITADEL وواجهة تسجيل الدخول الخاصة به وPostgreSQL والوكيل العكسي معًا، بدلًا من التعامل مع خدمة Go بمعزل.

متطلبات Keycloak من خادم VPS

توصي وثائق حاويات Keycloak بحد ذاكرة قدره 2 غيغابايت لعمليات نشر Keycloak الصغيرة الجاهزة للإنتاج. ينطبق هذا الرقم على حاوية Keycloak نفسها، لا على خادم VPS كامل يشغّل PostgreSQL أيضًا.

إذا تشارك Keycloak وPostgreSQL خادم VPS واحدًا، فإن 4 غيغابايت من ذاكرة النظام نقطة بداية معقولة. اعتبر ذلك إرشادًا عمليًا للمضيف لا الحد الأدنى الرسمي لـ Keycloak.

متطلبات Authelia من خادم VPS

لا تنشر Authelia حدًا أدنى للخادم قابلًا للمقارنة مباشرة من 1 غيغابايت أو 2 غيغابايت. حدّد حجم المضيف لـ Authelia مع الوكيل العكسي وخلفية التخزين ودليل المستخدمين وأي خدمات أخرى تتشارك الجهاز.

لدى Authelia عمومًا بصمة نشر أصغر من تشغيل IdP كامل إلى جانب PostgreSQL، لكن متطلبات VPS الفعلية تعتمد على بقية الحزمة.

مثال إعداد: Authentik مع Vaultwarden

أضاف Vaultwarden دعمًا أصليًا لتسجيل الدخول الموحّد عبر OpenID Connect في الإصدار 1.35.0 في ديسمبر 2025. Authentik مثال مفيد لأن التكامل يكشف عناصر OIDC التي ستصادفها أيضًا مع تطبيقات أخرى: عناوين URI لإعادة التوجيه، وبيانات اعتماد العميل، والنطاقات، وعناوين URL للمُصدر، والوصول للاسترداد.

إعداد Authentik الأساسي

في Authentik:

1. أنشئ تعيين نطاق بريد إلكتروني مخصصًا لـ Vaultwarden. يشترط Vaultwarden أن يعيد نطاق email إما القيمة email_verified: true أو لا يعيد أي قيمة email_verified على الإطلاق، بينما يعيد نطاق البريد الإلكتروني الافتراضي في Authentik حاليًا القيمة false.
2. أنشئ زوجًا من تطبيق وموفّر OAuth2/OpenID Connect.
3. أضف https://vault.example.com/identity/connect/oidc-signin بوصفه عنوان URI الصارم لإعادة التوجيه من نوع Authorization.
4. اختر أي مفتاح توقيع متاح.
5. دوّن Client ID وClient Secret وslug التطبيق.
6. اضبط صلاحية رمز الوصول على أكثر من خمس دقائق.
7. أضف تعيين offline_access الخاص بـ Authentik إلى النطاقات المحددة.
8. استبدل تعيين البريد الإلكتروني الافتراضي بتعيين البريد الإلكتروني المُتحقق منه المخصص من الخطوة 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 التطبيق ومعرّف العميل وسر العميل بالقيم من نشرك الخاص، ثم أعد تشغيل Vaultwarden.

اقرأ

استضافة ذاتية لمدير كلمات المرور Bitwarden: دليل كامل

ما الذي تختبره قبل فرض SSO

اترك SSO_ONLY على القيمة false أثناء اختبار تسجيل الدخول والخروج وتجديد الرموز ومطابقة الحسابات والاسترداد. واختبر أيضًا ما يحدث عندما يكون Authentik غير متاح مؤقتًا.

عندما يعمل كل من SSO والاسترداد كما هو متوقع، يمكنك أن تقرر ما إذا كان فرض SSO على كل تسجيل دخول منطقيًا لنشرك.

تنطبق مفاهيم OIDC نفسها على تطبيقات مستضافة ذاتيًا أخرى، لكن عناوين URI لإعادة التوجيه والنطاقات والمطالبات والتراخيص تختلف. راجع وثائق SSO لكل تطبيق بدلًا من نسخ إعداد Vaultwarden مباشرة.

متى تكون Authelia أفضل من IdP كامل

تصبح Authelia أكثر جاذبية عندما لا يحتاج التطبيق إلى فهم موفّر الهوية على الإطلاق.

المصادقة عند الوكيل العكسي

صُممت Authelia أساسًا لحماية التطبيقات عند طبقة الوكيل العكسي. تحدد أنت قواعد التحكم في الوصول، وتقرر Authelia ما إذا كان الطلب سيصل إلى الخلفية قبل أن يتولى التطبيق نفسه المصادقة.

حماية التطبيقات التي لا تدعم OIDC

هذا مفيد للأدوات الداخلية القديمة ولوحات المعلومات والخدمات التي لا تدعم OIDC أو SAML. بدلًا من تعديل كل تطبيق، يمكنك وضع المصادقة أمامه عند الوكيل العكسي.

يمكن لـ Authelia أيضًا العمل كموفّر OIDC، لكن المصادقة عند الوكيل العكسي تبقى نقطة قوتها الرئيسية.

استخدام Authelia مع Authentik معًا

يمكنك استخدام Authentik للتطبيقات التي تدعم OIDC أو SAML، وAuthelia للتطبيقات التي تحتاج إلى مصادقة عند الوكيل العكسي.

لست بحاجة بالضرورة إلى كليهما. يدعم Authentik أيضًا حماية التطبيقات عبر الوكيل، لذا لا يكون استخدام Authelia إلى جانبه منطقيًا إلا عندما يحل سير عمل الوكيل العكسي في Authelia جزءًا محددًا من حزمتك بشكل أنظف.

الأسئلة الشائعة

هل Authentik أفضل من Keycloak؟

بالنسبة إلى معظم المختبرات المنزلية وحزم التطبيقات المستضافة ذاتيًا الصغيرة، Authentik أسهل تناولًا. يركز سير عمل الإدارة فيه على التطبيقات والموفّرين والمجموعات والسياسات دون كشف هذا القدر من تعقيد IAM دفعة واحدة.

Keycloak أكثر منطقية عندما تحتاج تحديدًا إلى اتحاده الأعمق أو نموذج realm فيه أو Authorization Services. Authentik هو الخيار الافتراضي الأقوى لـ SSO مستضاف ذاتيًا أبسط؛ ويناسب Keycloak البيئات التي تحتاج إلى تلك الضوابط الإضافية.

هل ZITADEL أفضل من Keycloak؟

ZITADEL أنسب عندما تبني منتجًا وتريد هوية مُدارة عبر الواجهة البرمجية ومؤسسات وتعدد مستأجرين. وKeycloak أنسب عندما تحتاج إلى نموذج التفويض الأعمق فيه، أو ضوابط الاتحاد الواسعة، أو بيئة مبنية أصلًا حول Keycloak.

ما الفرق بين Authentik وAuthelia؟

Authentik موفّر هوية كامل مبني حول المستخدمين والمجموعات والتطبيقات والموفّرين والتدفقات والسياسات. يمكن للتطبيقات التكامل معه مباشرة عبر بروتوكولات مثل OIDC وSAML.

تتمحور Authelia حول المصادقة والتحكم في الوصول عند الوكيل العكسي. وتتضمن أيضًا موفّر OIDC، لكن الحماية عند الوكيل العكسي تبقى حالة الاستخدام الأساسية لها.

اختر Authentik عندما تتكامل التطبيقات مباشرة مع IdP. واختر Authelia عندما يجب أن تحدث المصادقة أساسًا قبل وصول الحركة إلى التطبيق.

هل يمكنني تشغيل Authentik على خادم VPS بذاكرة 1 غيغابايت؟

ليس كنقطة بداية مدعومة. تتطلب وثائق Docker Compose الحالية لـ Authentik نواتي معالج و2 غيغابايت RAM على الأقل. يستخدم النشر الأساسي الحالي خادم Authentik والعامل worker وPostgreSQL؛ وقد أُزيل Redis تمامًا في Authentik 2025.10.

اعتمد 2 غيغابايت نقطة بداية دنيا لتثبيت صغير، وأضف هامشًا عندما تتشارك خدمات أخرى الجهاز.

هل يدعم Vaultwarden تسجيل الدخول الموحّد عبر OIDC؟

نعم. أضاف Vaultwarden دعم تسجيل الدخول الموحّد عبر OpenID Connect في الإصدار 1.35.0 في ديسمبر 2025. ويتطلب موفّر OIDC خارجيًا مثل Authentik أو Keycloak أو ZITADEL.

يعتمد الإعداد الدقيق على الموفّر. مع إصدارات Authentik الحالية، يتضمن التكامل الموثق تعيين نطاق بريد إلكتروني مُتحقق منه مخصصًا، وoffline_access، وبيانات اعتماد العميل، وعنوان URL لمُصدر تطبيق Authentik.

هل أشغّل IdP على خادم VPS نفسه مع تطبيقاتي؟

لمختبر منزلي يُقبل فيه التوقف، قد تكون الاستضافة المشتركة معقولة. أما للتطبيقات الحرجة للأعمال، فيمنح خادم VPS المنفصل موفّر الهوية ميزانية موارد خاصة به ويزيل خادم التطبيقات من نطاق الفشل المشترك.

لا يخلق ذلك توافرًا عاليًا بحد ذاته، لكن إعادة تشغيل خادم التطبيقات أو مشكلة في الموارد أو اختراقًا لم يعد يسقط IdP معه تلقائيًا.

أي حل SSO مستضاف ذاتيًا هو الأسهل استخدامًا؟

Authentik هو نقطة البداية الأسهل لمعظم من يربطون تطبيقات مستضافة ذاتيًا قائمة. تجعل واجهة الإدارة فيه التطبيقات والموفّرين والمجموعات والسياسات أسهل تناولًا من نموذج realm والتفويض الأوسع في Keycloak.

قد تكون Authelia أبسط عندما تحتاج فقط إلى المصادقة عند الوكيل العكسي. وZITADEL أكثر منطقية عندما يكون من يضبط الهوية مطوّرًا يعمل أساسًا عبر الواجهات البرمجية.