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

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

تتناول هذه المقالة منصات CIAM الأربع ذاتية الاستضافة التي يمكن لفريق SaaS صغير في مجال B2B تشغيلها فعليًا دون أن تتحول إلى وظيفة ثانية بدوام كامل: ZITADEL وFusionAuth وLogto وOry Hydra. ليست كلها على الشكل نفسه، والخيار المناسب لك يعتمد على نوع منتج B2B الذي تبنيه أكثر مما يعتمد على قائمة ميزات. شغّلتها جنبًا إلى جنب على خادم VPS واحد لمدة أسبوع لإعداد هذه المقارنة، وما يلي هو النسخة التي كنت سأرسلها إلى مؤسِّس يراسلني بشأن CIAM.

توضيح مسبق: الحديث هنا عن CIAM بوصفه ميزة في المنتج، لا عن تسجيل الدخول الموحّد الداخلي لفريقك.

النسخة المختصرة

أربع منصات CIAM ذاتية الاستضافة، سطر واحد لكل منها:

• ZITADEL إذا كنت تريد تعدد المستأجرين ومنظمات B2B جاهزة منذ البداية.
• FusionAuth إذا كنت تريد واجهة إدارة متقنة وسجل إصدارات طويلًا ويمكن التنبؤ به.
• Logto إذا كنت تريد أنظف تجربة للمطوّر منذ اليوم الأول.
• Ory Hydra إذا كنت تبني على مستوى البروتوكول وتريد محرك OAuth 2.0 لا تطبيق تسجيل دخول جاهزًا بخيارات مفروضة.

الخلاصة: ZITADEL هو الرهان الأول الأكثر أمانًا لمنتج SaaS بنموذج B2B اعتيادي، وبقية المقالة تفصّل هذا المنطق.

لماذا يختلف قرار CIAM عن قرار تسجيل الدخول الموحّد للموظفين

إذا تعطّل تسجيل الدخول الموحّد لفريقك الداخلي، فالضرر محدود عادةً. قد يفقد مهندسوك الوصول إلى Grafana أو أداة داخلية أخرى لساعة. أما إذا تعطّل CIAM فلن يتمكن عملاؤك الدافعون من تسجيل الدخول إلى المنتج إطلاقًا. وهذا ينقل السؤال من "أي أداة مصادقة مريحة لفريقنا؟" إلى "أي نظام مصادقة نثق به بوصفه جزءًا من المنتج نفسه؟"

يحتاج CIAM، وهو نوع البنية التحتية للهوية الذي يتطلبه منتج SaaS بنموذج B2B، إلى بدائيات لا تُبرزها كثير من أدوات تسجيل الدخول الموحّد للموظفين. عميلك ليس مستخدمًا واحدًا، بل مؤسسة (مستأجر) لها مستخدموها وأدوارها وهويتها البصرية، وربما اتصال SAML خاص بها بمزوّد هوية مؤسسي. أنت لا تصادق أشخاصًا فحسب، بل تعزل مستخدمي شركة عن مستخدمي شركة أخرى داخل المنتج نفسه. هذا هو الشكل الذي تستهدفه الأدوات الأربع أدناه، كل واحدة بطريقتها. أصبح لدى Keycloak الآن Organizations بوصفها مفهومًا أساسيًا، لذا فإن استبعاده باعتباره أداة للموظفين فقط صار رأيًا قديمًا؛ أشرح سبب عدم إدراجه في الأسئلة الشائعة.

مثلث البناء والشراء والاستضافة الذاتية يبدو مختلفًا هنا أيضًا. كتابة OAuth من الصفر خطأ لا مبرر له. أنت تطلق منتج SaaS، لا مزوّد هوية. شراء خدمة مُدارة (Auth0 أو Clerk أو WorkOS) هو القرار الصحيح حين لا تملك فرقك أي طاقة تشغيلية ولديك ميزانية معقولة. لن أنصح أبدًا شركة ناشئة من شخصين باستضافة المصادقة ذاتيًا في اليوم الأول. تصبح الاستضافة الذاتية منطقية حين يتجاوز تسعير CIAM المُدار لكل مستخدم نشط شهريًا تكلفة البنية التحتية مضافًا إليها وقت الهندسة المستمر، أو حين تحتاج إلى تحكم مباشر في النشر وطبقة البيانات. في الفرق التي عملت معها، تأتي هذه النقطة عادةً بين "صار لدينا منتج حقيقي" و"صار لدينا فريق نجاح عملاء حقيقي".

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

الأدوات الأربع، واحدة تلو الأخرى

اخترت هذه الأربع لأنها قريبة بما يكفي من شكل CIAM بحيث يمكن تقييمها بوصفها بنية تحتية للمنتج، لا مجرد تسجيل دخول موحّد داخلي. توفّر ZITADEL وFusionAuth وLogto وOry جميعها مسارًا حقيقيًا للاستضافة الذاتية وانتشارًا كافيًا لأخذها على محمل الجد. أما الخيارات التي هي مجرد مكتبات، وتلك الموجّهة لتسجيل دخول الموظفين، والأقل نضجًا، فمعالجتها في الأسئلة الشائعة أنسب.

ZITADEL

ZITADEL منصة هوية سويسرية المنشأ مكتوبة بلغة Go، بمعمارية قائمة على تدفّق الأحداث وواجهة خلفية على PostgreSQL. حتى 27 يوليو 2026، أحدث إصدار لها على GitHub هو the 4.16 series, current as of July 2026. انتقل ZITADEL من Apache 2.0 إلى AGPL-3.0 بدءًا من الإصدار v3؛ وفي الاستخدام الاعتيادي لمنتجات SaaS يكون الأثر العملي أقل إرباكًا مما يبدو عادةً، وأتناول التفاصيل في الأسئلة الشائعة.

ما يميّز ZITADEL في مجال SaaS بنموذج B2B: المنظمات وتعدد المستأجرين بدائيات من الدرجة الأولى، لا ميزات تركّبها من كائنات عامة. تنشئ Organization فتحصل على مستخدميها وسياساتها وهويتها البصرية وإعدادات الوصول الخاصة بها، ويمكنك منحها مشاريع ليتولى مسؤولوها إسناد الأدوار لمستخدميهم. لست مضطرًا لاختراع مفهوم "المستأجر" فوق مستخدمين عامّين. تبدأ به منذ البداية.

تجربة المطوّر قائمة على واجهات برمجية أولًا، مع واجهات موارد REST من الإصدار v2 الحالي إضافة إلى وصول عبر gRPC وREST إلى خدمات v1 القديمة. تغطي حزم التطوير الرسمية وحزم المجتمع أشهر منصات الخوادم. لوحة الإدارة عملية لكنها أبسط من لوحة FusionAuth.

قراءتي: إذا كنت تبني منتج SaaS بنموذج B2B وتعلم أنه سيكون لديك مستأجرون، فسأبدأ من ZITADEL. فهو، بين الخيارات ذاتية الاستضافة، الأكثر وضوحًا في تشكيله حول مشكلة تسجيل الدخول في B2B.

FusionAuth

FusionAuth منصة أمريكية من Inversoft, LLC (شركة ذات مسؤولية محدودة في ديلاوير تعمل باسم FusionAuth) موجودة منذ وقت أطول من الثلاث الأخرى، وهذا يظهر بالمعنى الجيد. تبدو واجهة الإدارة أكثر عناية بالتصميم من غيرها بوضوح، والتوثيق ناضج، وإيقاع الإصدارات ثابت لا محموم. إذا سبق أن ورثت تكاملًا للمصادقة عمره أربع سنوات وشكرت في سرّك المهندس السابق لأنه اختار الخيار الممل، فإن FusionAuth هو إصدار CIAM الذي يستحق هذا الشكر.

ما يربك الناس هو الترخيص: يمكن استضافة FusionAuth Community ذاتيًا مجانًا، لكن المنتج الأساسي ليس مفتوح المصدر. يخضع المنتج لـ ترخيص FusionAuth الخاص، وتصبح هذه الحدود مهمة إذا كنت تنوي إعادة التوزيع أو التضمين أو تغيير العلامة أو إعادة البيع أو استضافة FusionAuth لعملائك. تغطي نسخة Community ذاتية الاستضافة الحالة الأساسية لمنتج SaaS بنموذج B2B؛ تضيف الخطط المدفوعة ميزات مثل SAML الذي يبدأ من مزوّد الهوية، والمصادقة متعددة العوامل المتقدمة، والسمات الخاصة بكل تطبيق، بينما يقع SCIM وTenant Manager وسياسات MFA على مستوى التطبيق ضمن خطة Enterprise.

أما شكل B2B: يُنمذج FusionAuth المستأجرين والتطبيقات، لكن التجريد أقرب إلى "مصادقة معزولة في حاوية لكل مستأجر" منه إلى "منظمات B2B ككائن في المجال". هذا ينجح (أطلقت منتجات فوقه)، لكن تعدد المستأجرين يبدو أقرب إلى بدائية عزل منه إلى نموذج B2B من الدرجة الأولى. أما حزم التطوير الرسمية ومكتبات العميل فواسعة:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

مكتبات جانب الخادم عبارة عن عملاء API خفيفة. ولوحة الإدارة أسهل نسبيًا في تسليمها إلى شخص تشغيل غير مهندس مقارنةً بالبقية.

قراءتي: إذا كان فريقك يقدّر إتقان الواجهة وسجلًا طويلًا يمكن التنبؤ به أكثر من البدائيات المصمَّمة أصلًا لـ B2B، فاختر FusionAuth. إنه الخيار الأكثر "مللًا" هنا، وهذا إطراء.

Logto

Logto هو الأحدث بين الأربعة، تطوّره شركة Silverhand Inc. وهو مرخَّص بموجب MPL-2.0، وهو الأكثر وضوحًا في اهتمامه بلوحة التحكم الخاصة به. الإعداد في اليوم الأول سريع نسبيًا. تُنشئ الخادم، وتمرّ عبر المعالج، فتحصل خلال خمس عشرة دقيقة تقريبًا على مزوّد OIDC يعمل بواجهة تسجيل دخول افتراضية محترمة (قِسْتُ ذلك في الأسبوع الذي شغّلت فيه الأربعة جنبًا إلى جنب). تغطي أدلة البدء السريع الرسمية أطر العمل ومنصات الخوادم الحديثة، فإذا كانت حزمتك "Next.js + Postgres + شيء ما" فستشعر بأنك في بيتك.

إجابته عن B2B تُسمّى Logto Organizations. يغطّي البدائيات الأساسية لـ B2B: عضوية المنظمة، والأدوار المحصورة بالمنظمة، ودعوات الأعضاء، والتزويد الفوري، وتكامل تسجيل الدخول الموحّد المؤسسي. نموذج المنظمة عنده أحدث من نموذج ZITADEL، لذا سأختبر أي تدفّق SAML أو SCIM أو اتحاد هوية غير اعتيادي مع عملائك المستهدفين قبل الالتزام.

المفاضلة هنا في النضج: Logto هو الخيار الأحدث في هذه القائمة. خارطة الطريق تتحرك بسرعة، وهذا رائع حين تصل ميزة تحتاجها، ومزعج حين يصل تغيير كاسر للتوافق. إذا كان منتج SaaS بنموذج B2B لديك في الطرف الأبسط من طيف تعدد المستأجرين (عدد صغير من المنظمات ولا متطلبات اتحاد هوية غريبة)، فإن تجربة المطوّر في Logto تجعل بقية القرار أسهل.

قراءتي: إذا كنت تريد أسرع يوم أول وكانت احتياجاتك في B2B ما زالت بسيطة نسبيًا، فاختر Logto.

Ory Hydra (وحزمة Ory)

Ory Hydra هو خادم OAuth 2.0 / OpenID Connect ضمن منظومة Ory، مرخَّص بموجب Apache-2.0. تجمع حزمة Ory الكاملة بين Hydra وOry Kratos (الهوية وإدارة المستخدمين وتسجيل الدخول الذاتي والتسجيل والمصادقة متعددة العوامل واستعادة الحساب) وOry Keto (خادم تفويض على نمط Zanzibar يعمل كنقطة قرار للسياسات) وOry Oathkeeper (وكيل هوية ووصول يتولى المصادقة والتفويض وتعديل طلبات HTTP الواردة). تُركّب ما تحتاجه فقط. كل شيء مكتوب بلغة Go والواجهات البرمجية نظيفة.

المسألة (وهذه ليست عيبًا؛ بل ميزة للفريق المناسب) أن Hydra هو المحرّك لا التطبيق. فبحكم التصميم، يتصل Hydra بتطبيق منفصل لتسجيل الدخول والموافقة تُوفّره أنت. إذا كنت تريد شاشة تسجيل دخول جاهزة، فهذه ليست الأداة المناسبة. أما إذا كنت تبني شيئًا يكون فيه تدفّق المصادقة جزءًا من المنتج (منصة للمطوّرين، أو بوابة B2B مخصصة، أو منتج قائم على الواجهات البرمجية أولًا بتجربة انضمام خاصة)، فإن غياب واجهة مفروضة هو بالضبط ما تريده.

قصة B2B هنا قابلة للتركيب لا جاهزة بالكامل. يمكنك نمذجة تعدد المستأجرين بربط مخططات Kratos وعلاقات Keto بطبقة المنظمات الخاصة بك، وهذا ينجح، لكن التوصيل تقوم به أنت. الكلفة مزيد من أعمال السباكة، والعائد تحكّم في التجربة. توثيق Ory يغطي سطح البروتوكول بعمق، لكن النموذج القابل للتركيب يفترض أنك مرتاح لاتخاذ قرارات على مستوى البروتوكول بنفسك. وإذا كانت "audience claim" أو "PKCE" لا تعني لك شيئًا، فابدأ بواحد من الثلاثة الأخرى.

قراءتي: إذا كنت تبني شيئًا على مستوى البروتوكول (بوابة مصادقة، أو تدفّقات مخصصة، أو منصة للمطوّرين) وتشعر أن التطبيقات الجاهزة تقيّدك، فإن Ory هو الجواب الصحيح. أما لمنتج SaaS بنموذج B2B اعتيادي يريد تسجيل دخول يعمل اليوم، فلا.

المقارنة في لمحة

إليك ملخص الأدوات الأربع في جدول واحد، مفيد للقراءة الثانية، لا بديلًا عن قراءة الأوصاف أعلاه.

بأيّها ينبغي أن تبدأ؟

أربعة سيناريوهات قصيرة تغطي معظم الفرق التي أتحدث معها في هذا الشأن.

أنت تبني منتج SaaS بنموذج B2B وتعلم أنه سيكون لديك مستأجرون. ابدأ بـ ZITADEL. فبدائيات تعدد المستأجرين والمنظمات مصمَّمة لهذا تحديدًا، وسطح الواجهات البرمجية شامل، وستقضي وقتًا أقل في اختراع نموذج المستأجر مقارنةً بأي من الثلاثة الأخرى. يستحق التحول إلى AGPL مراجعة قانونية، لكن نشرًا غير معدَّل ومُدمجًا بشكل منفصل يكون عادةً حالة استخدام SaaS مباشرة.

تريد واجهة إدارة متقنة ومنصة مستقرة يمكن التنبؤ بها. FusionAuth. تغطي خطة Community الاحتياجات الأساسية لكثير من الفرق؛ خصّص وقتًا لقراءة الترخيص ومصفوفة الميزات بعناية. ميزات مثل SAML الذي يبدأ من مزوّد الهوية، والمصادقة متعددة العوامل المتقدمة، والسمات الخاصة بكل تطبيق تتطلب خطة مدفوعة، بينما يقع SCIM وTenant Manager وسياسات MFA على مستوى التطبيق ضمن Enterprise.

احتياجاتك في B2B بسيطة اليوم وتريد أسرع يوم أول. Logto. كانت تجربة المطوّر في اليوم الأول عنده الأسرع في اختباري المتوازي. تقبّل أنك تراهن على منظومة أحدث سنًا، وأعد النظر في الاختيار إذا نمت متطلباتك إلى حالات حدّية في اتحاد الهوية لم تختبرها.

أنت تبني شيئًا تكون فيه تدفّقات المصادقة جزءًا من تجربة المنتج. Ory Hydra (مع Kratos، ومع Keto إذا كنت تحتاج إلى الصلاحيات). ستكتب شيفرة أكثر. وسيكون لديك تحكّم أكبر. وإذا لم تكن هذه المقايضة بديهية بالنسبة لك، فأنت لست جمهور Ory. اذهب واختر واحدًا من الثلاثة الأخرى.

إذا انطبق عليك وصفان من هذه الأوصاف، فاجعل ZITADEL خيارك الافتراضي. فهو الأوسع ملاءمة، وهو ما كنت سأسلّمه لفريق تأسيسي صغير دون كثير من الأسئلة الإضافية.

ما تكلّفك إياه الاستضافة الذاتية (تشغيليًا)

وهنا يأتي الجزء غير الرومانسي من المقالة.

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

إيقاع الإصدارات يتغيّر بمرور الوقت. صدر ZITADEL v4.16.1 في 17 يوليو 2026 بعد عدة إصدارات في يونيو، فيما يحافظ كل مشروع هنا على إيقاعه وسياسته الخاصة بالتوافق. تعامل مع هذا الإيقاع بوصفه شأنًا يخص الصيانة، لا اختصارًا للحكم على الجودة. اقرأ ملاحظات الإصدار قبل تشغيل docker compose pull، وحدّد نافذة دورية للترقيع. تخطّي تحديثات مزوّد الهوية لأشهر قد يتركك متأخرًا عن إصلاحات الأمان والتوافق عند أول مراجعة جدّية.

الأمور الاعتيادية التي تتسلّل إليك دائمًا: تجديد شهادات TLS (استخدم وكيلًا عكسيًا مع Let's Encrypt، وأتمِت التجديد، ونبّه عند الإخفاق)، وتهيئة خادم البريد الصادر لرسائل التحقق وإعادة تعيين كلمة المرور (SES أو SendGrid أو Postmark: اختر واحدًا واضبط SPF/DKIM/DMARC كما ينبغي وإلا انتهت رسائل إعادة التعيين في البريد المزعج)، وتدوير بيانات اعتماد عملاء OAuth حين يغادر مهندس، وتحديد معدّل الطلبات على نقاط تسجيل الدخول كي لا يشل هجوم حشو بيانات الاعتماد وحدة المعالجة لديك.

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

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

أين تنشرها

قد يكون خادم VPS بنظام Linux يشغّل Docker Compose نقطة انطلاق معقولة للتقييم والأحمال المتواضعة، لكن تحديد الحجم في الإنتاج والتوافر العالي يعتمدان على حجم الحركة ومتطلبات الأمان ومدى تحمّلك للتوقف. وإليك موقع خيارات النشر الشائعة:

• الاستضافة المشتركة لا تستطيع تشغيل أي منها. فهي تحتاج إلى تخزين دائم ومنافذ مخصصة وصلاحية الجذر لبيئة تشغيل الحاويات وواجهة خلفية حقيقية لقاعدة البيانات. PostgreSQL هو المسار الافتراضي لمعظم هذه القائمة، لكنه حرفيًا ليس قاعدة البيانات الوحيدة المدعومة لكل أداة.
• Kubernetes يستطيع تشغيل الأربعة جميعًا، لكن المسار الرسمي غير متكافئ. ZITADEL, FusionAuth، و Ory تنشر مخططات Helm رسمية، بينما توثيق الاستضافة الذاتية لـ Logto يركّز على النشر عبر Docker والأجهزة الافتراضية. أما لمنتج SaaS صغير بنموذج B2B لم يبلغ بعد النقطة التي يسدّد فيها Kubernetes تكلفته في مواضع أخرى، فهذا عادةً هندسة زائدة عن الحاجة. لجّئ إليه حين تكون بقية بنيتك التحتية هناك أصلًا.
• الخوادم الفيزيائية لا بأس بها إن كنت عليها أصلًا. ومعظم فرق SaaS بنموذج B2B ليست كذلك.

لتجربة صغيرة على عقدة واحدة، سأبدأ بذاكرة 4 GB و2 vCPU و60 GB من تخزين NVMe، ثم أختبر تدفّق تسجيل الدخول الحقيقي تحت الحمل. هذا خط أساس للتخطيط لا حدًّا أدنى إنتاجيًا شاملًا. التطبيقات خفيفة نسبيًا، لكن PostgreSQL يحتاج ذاكرة وتجزئة كلمات المرور تحتاج هامشًا في المعالج. إرشادات ZITADEL للإنتاج توصي بإتاحة أربع أنوية معالجة لذُرى تجزئة كلمات المرور.

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

تشغيل CIAM في الإنتاج يعني أن جاهزيته صارت مشكلتك أنت. نحن نشغّل خوادم Cloudzy Linux VPS لهذا النوع من الأحمال، مع تخزين NVMe واتفاقية مستوى خدمة للجاهزية بنسبة 99.95% على المنصة الأساسية. كما تقدّم Cloudzy خادم VPS بنقرة واحدة لـ ZITADEL إن كنت تفضّل تخطّي سكربت التزويد الأولي؛ أما الثلاثة الأخرى فتوفّر صور حاويات رسمية للإعداد عبر Docker. وللحصول على نظرة على مستوى الإدارة حول موقع التحكم في الوصول ضمن بقية وضعك الأمني، يتناول دليل أفضل ممارسات IAM الموضوع من زاوية السياسات.

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

هل يؤثّر ترخيص AGPL الخاص بـ ZITADEL على منتج SaaS الخاص بي؟

عادةً لا، إذا كان النشر غير معدَّل ومُدمجًا بشكل منفصل، لكن هذا ليس استشارة قانونية. تنطبق التزامات AGPL الخاصة بـ ZITADEL على ZITADEL نفسه. فإذا عدّلت ZITADEL وشغّلت النسخة المعدَّلة كخدمة عبر الشبكة، فقد يُلزمك الترخيص بإتاحة الشيفرة المصدرية المقابلة بموجب AGPL. والموقف المنشور لـ ZITADEL هو أن مجرد استخدام نسخة غير معدَّلة كخدمة هوية لمنتج SaaS لديك لا يُلزمك بذاته بترخيص تطبيقك المنفصل بموجب AGPL. اقرأ إعلان الترخيص من ZITADEL واحصل على استشارة قانونية إن كنت ستعدّل البرنامج أو تعيد توزيعه أو تضمّنه أو تقدّمه لأطراف ثالثة. كما يتوفّر ترخيص تجاري.

لماذا لا يظهر Keycloak أو Authentik في هذه القائمة؟

‏Keycloak وAuthentik أداتا هوية ذاتية الاستضافة ممتازتان (وأنا أستخدمهما)، لكن استبعاد Keycloak بحجّة افتقاره لمنظمات B2B صار خطأً الآن: فإصدارات Keycloak الحالية تتضمّن Organizations ومجموعات المنظمات وأدوات الإدارة المفوَّضة. تركته خارج القائمة لأن هذه المقارنة تركّز على أربعة خيارات ذات مسار أكثر مباشرة لفريق صغير يبني SaaS بنموذج B2B؛ ويستحق Keycloak تقييمًا خاصًا به حين تكون إدارة الـ JVM وعمق المنظومة والمرونة على مستوى الـ realm أمورًا مهمة. أما Authentik فيبقى أنسب لتسجيل الدخول الموحّد للموظفين والتطبيقات الداخلية منه لنمذجة المستأجرين داخل المنتج.

هل الاستضافة الذاتية أرخص من Auth0؟

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

ما الحد الأدنى لحجم خادم VPS لتشغيل CIAM في الإنتاج؟

لتجربة صغيرة على عقدة واحدة، تُعدّ ذاكرة 4 GB و2 vCPU وتخزين NVMe نقطة انطلاق معقولة، لا ضمانة إنتاجية. حدّد الحجم انطلاقًا من بصمة قاعدة بياناتك، وحمل تسجيلات الدخول المتزامنة، وكلفة تجزئة كلمات المرور، وهدفك في الجاهزية. توصي إرشادات ZITADEL للإنتاج نفسها بإتاحة أربع أنوية معالجة لذُرى التجزئة؛ أما الأدوات الأخرى وأنماط الحركة المختلفة فتحتاج اختبارات حمل خاصة بها.

هل يمكنني لاحقًا الانتقال من CIAM مُدار إلى الاستضافة الذاتية؟

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