لماذا يصبح SSO ميزة مدفوعة في البرمجيات المستضافة ذاتياً؟

ما هو رسم SSO

رسم SSO في البرمجيات المستضافة ذاتياً هو نمط تكون فيه الخدمة مجانية، بينما يكون تسجيل الدخول الموحد (SSO) الميزة الوحيدة التي يجب عليك شراؤها. يمكنك تشغيل البرنامج بالكامل على VPS تملكه، من دون مفتاح ترخيص ومن دون حد لعدد المستخدمين. ثم تفتح صفحة المصادقة في الوثائق، فتجد OpenID Connect (OIDC) أو SAML (لغة ترميز تأكيدات الأمان) ضمن خطة مدفوعة.

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

هذا النمط قديم بما يكفي لوجود قائمة عامة تتعقبه. تسرد قائمة SSO Wall of Shame على sso.tax المورّدين الذين يفرضون سعراً إضافياً كبيراً مقابل تسجيل الدخول الموحد، وتضم إدخالات تعود إلى 2018، كما يضع مؤلفها معياراً منصفاً: "إذا كانت تكلفة دعم SSO لديك زيادة قدرها 10% في السعر، فلن تظهر في هذه القائمة." معظم العناصر في تلك القائمة تخص برمجيات مغلقة المصدر. وتظهر منطقية التسعير نفسها الآن في مشاريع مفتوحة المصدر تستضيفها بنفسك.

لماذا يضع المشرفون تسجيل الدخول الموحّد ضمن فئة مدفوعة

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

تكلفة الدعم حقيقية لأن تكامل الهوية لا يكتمل أبداً. ينسّق كل IdP المطالبات بطريقة تختلف قليلاً عن غيره. ويتسبب كل من تعيين المجموعات، ومدة الجلسة، وعناوين إعادة التوجيه، وانحراف الساعة في أخطاء تسجيل الدخول. ويؤدي خطأ تسجيل الدخول إلى منع جميع المستخدمين من الدخول في الوقت نفسه، لذلك تكون هذه التذاكر عاجلة. ثم تأتي الطلبات اللاحقة: المجموعات المتداخلة، وتعيين الأدوار، والتوفير التلقائي باستخدام SCIM (نظام إدارة الهوية عبر النطاقات)، وسجلات التدقيق التي سيقرأها فريق الامتثال.

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

تصحيح واحد للشكوى المعتادة: راجع سجل التغييرات قبل أن تفترض إزالة ميزة، لأن الإزالة تظهر في ملاحظات الإصدار. في المشاريع التي راجعتها لهذا المنشور، بُنيت ميزات تسجيل الدخول الموحّد المدفوعة للفئة المدفوعة منذ البداية. لم أجد حالة سُحب فيها تسجيل دخول موحّد مجاني كان يعمل. وتُعد Grafana مثالاً نموذجياً هنا. تحتوي صفحة SAML فيها على ملاحظة من سطر واحد تقول: "متاح في Grafana Enterprise وGrafana Cloud"، بينما يعمل OAuth العام باستخدام issuer الخاص بك في إصدار open source.

ما الذي تكلّفك إياه ضريبة SSO فعلياً

المال هو الجزء الأصغر. تُباع الخطط المدفوعة لكل مستخدم، لذلك ترتفع الفاتورة مع نمو فريقك، بينما تبقى الاستضافة والترقيات من مسؤوليتك.

أما التكلفة الأكبر فهي العمل اليدوي المتعلق بالهويات، وتظهر في أربعة مواضع.

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

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

قائمة التحقق التي يجب تنفيذها قبل اعتماد أي شيء

نفّذ هذه القائمة قبل docker compose up، وليس بعد أن يحتفظ التطبيق بـ400 مستند.

1. افتح صفحة المصادقة في الوثائق واقرأ ملاحظة الخطة في الأعلى. تكون الميزات المدفوعة مرفقة بشارة أو بجملة قصيرة توضّح مدى توفرها.
2. تأكد من أن التطبيق يدعم OIDC أو SAML مع موفّر الهوية الخاص بك، بدلاً من الاتصال بقائمة ثابتة من الموفّرين العامين.
3. تحقق من تعيين الأدوار والمجموعات. إنشاء المستخدم ليس سوى نصف المهمة، أما النصف المرهق فهو تعيين الصلاحيات يدوياً في 10 تطبيقات.
4. تحقق مما إذا كان التطبيق يقبل اسم مستخدم موثّقاً في ترويسة من Reverse Proxy موثوق، وما إذا كان بإمكانك تحديد الـProxy الذي يثق به.
5. اقرأ سجل التراخيص في git، وتحقق مما إذا كان المساهمون يوقّعون CLA (اتفاقية ترخيص المساهمين).
6. تحقق من إجراءات إلغاء الوصول عند مغادرة المستخدم. اعرف ما يحدث لرموز API (واجهة برمجة التطبيقات) والجلسات النشطة عند تعطيل حساب IdP.

البند 2 هو مصدر معظم خيبات الأمل. زر «تسجيل الدخول باستخدام Google» ليس OIDC مع موفّر الهوية الخاص بك؛ بل هو تكامل ثابت مع مورّد واحد. يتطلب الدعم الحقيقي أن تدخل عنوان URL للجهة المُصدرة، ويأتي كل شيء آخر من الاكتشاف. يمكنك تأكيد جانب موفّر الهوية لديك باستخدام أمر واحد.

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

تُرجع الجهة الموفّرة السليمة 3 عناوين URL. تعني النتيجة الفارغة أو 404 عادةً أن مسار الاكتشاف غير صحيح، وهذا المسار يختلف حسب الموفّر: ينشر Keycloak هذا المسار تحت /realms/<realm>/.well-known/openid-configuration. إذا لم يتضمن التطبيق حقلاً لعنوان URL للجهة المُصدرة، فلا يمكنه الاتصال بـIdP، مهما ذكرت قائمة الميزات.

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

ما الذي توضحه شارات الفئات فعلياً

تم التحقق من هذه المعلومات مقابل وثائق كل مشروع في August 2026. ابدأ بالخيارات المدفوعة.

تذكر Grafana أن SAML «متاح في Grafana Enterprise وGrafana Cloud»، إلى جانب مزامنة الفرق والتزويد عبر SCIM. أما Generic OAuth وGitHub OAuth وLDAP (بروتوكول الوصول إلى الدليل خفيف الوزن) وauth proxy، فهي متاحة جميعاً في الإصدار مفتوح المصدر، لذلك لا يزال بإمكان من يدير خادماً صغيراً تسجيل الدخول عبر موفّر الهوية الخاص به. يظهر الحد المدفوع عند SAML، وليس عند تسجيل الدخول الموحّد عموماً. وهذه هي النقطة الدقيقة التي غالباً ما تختزلها عبارة «ضريبة SSO».

توضح Metabase الأمر بشكل مباشر أكثر. تقول وثائقها: «مصادقة SAML متاحة فقط في خطتي Pro وEnterprise (سواء عند الاستضافة الذاتية أو على Metabase Cloud).» ويحتفظ الإصدار مفتوح المصدر بتسجيل الدخول باستخدام كلمة المرور وLDAP.

تضع Passbolt وثائق SSO ضمن Pro وCloud، لذلك لا يتضمنها إصدار المجتمع. وتشمل موفّرات الهوية الموثقة Keycloak وEntra ID.

والآن الجانب الآخر، لأن هذا النمط ليس عاماً على الإطلاق.

• يحمل GitLab Self-Managed العبارة «Tier: Free, Premium, Ultimate» في صفحة SAML الخاصة به، لذلك لا تكلّف مصادقة SAML مقابل GitLab الخاص بك شيئاً.
• يضبط Paperless-ngx ‏OIDC عبر django-allauth باستخدام PAPERLESS_SOCIALACCOUNT_PROVIDERS، ويخفي نموذج تسجيل الدخول المحلي باستخدام PAPERLESS_DISABLE_REGULAR_LOGIN، ويربط المطالبات بالمجموعات باستخدام PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• يقبل Planka ‏OIDC_ISSUER وOIDC_CLIENT_ID وOIDC_CLIENT_SECRET، ويضبط نطاقاته افتراضياً على openid profile email، ويرفع المستخدمين إلى دور المسؤولين من مطالبة الدور باستخدام OIDC_ADMIN_ROLES.
• ينتقل BookStack إلى الاستخدام عبر AUTH_METHOD=oidc، ثم يربط مجموعات الموفّر بأدواره الخاصة باستخدام OIDC_USER_TO_GROUPS=true وOIDC_GROUPS_CLAIM.
• أضاف Vaultwarden «دعم SSO باستخدام OpenID Connect» في الإصدار 1.35.0 بتاريخ 27 December 2025، عبر طلب دمج من مساهم كان قد حافظ على الميزة في fork.
• يدعم listmonk تسجيل الدخول عبر OIDC إلى جانب أدوار المستخدمين منذ الإصدار v4.0.0.

استخدم هذه المعلومات عند الاختيار، لا بعد الالتزام بمشروع معين. لا تتعامل لوحة Planka بنمط كانبان وغيرها من بدائل Trello المستضافة ذاتياً مع الهوية بالطريقة نفسها، وينطبق الأمر نفسه على BookStack وWiki.js وOutline. يمكنك تقييم OIDC المجاني كما تقيّم حدود التخزين أو تطبيقات الأجهزة المحمولة. إذا كنت لا تزال تعدّ القائمة، فإن ما الذي ينبغي استضافته ذاتياً في 2026 نقطة بداية مناسبة، كما أن كلاً من مدير المستندات Paperless-ngx وVaultwarden يوفّر OIDC مجاناً اليوم.

لماذا لا يُعدّ وضع Reverse Proxy أمام التطبيق تسجيل دخول موحّداً

الحل الشائع هو المصادقة بالوكالة. يحتجز Reverse Proxy كل طلب، ويسأل خدمة مصادقة عمّا إذا كان هذا المتصفح قد سجّل الدخول، ثم يمرّر الطلب إلى التطبيق فقط بعد ذلك. يسمّي authentik هذا الإعداد موفّر proxy، مع وضع forward auth لتطبيق واحد ووضع آخر لنطاق كامل. وتؤدي Authelia وoauth2-proxy المهمة نفسها.

يبدو مقطع الموقع في Caddy كما يلي، وفقاً للمثال الخاص بـ authentik.

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

تؤثر كتابة أسماء هذه الرؤوس بالأحرف الكبيرة والصغيرة في Caddy، لأن الاسم غير المطابق يصل فارغاً. في كل طلب يوافق عليه، يضبط outpost القيم X-authentik-username وX-authentik-email وX-authentik-groups وبعض القيم الأخرى.

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

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

جعل المصادقة عبر الرؤوس آمنة

تقبل بعض التطبيقات اسم مستخدم من الـproxy، ما يوفّر هوية لكل مستخدم من دون استخدام SSO مدفوع. يختلف اسم الإعداد من مشروع إلى آخر.

يسمّي Grafana هذه الميزة auth proxy، وتأتي معطّلة افتراضياً. يكون اسم الرأس الافتراضي هو X-WEBAUTH-USER، ويمكنك ضبطها على أي رأس يعيّنه الـproxy لديك.

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

يُعد whitelist السطر الذي يتجاهله كثيرون. توضّح وثائق Grafana أنه موجود لمنع المستخدمين من انتحال قيمة الرأس، لذلك يجب أن يحتوي على عنوان الـproxy فقط، دون أي شيء آخر. توفّر Gitea الميزة نفسها بأسماء مختلفة، وتأتي بإعداد افتراضي أكثر أماناً.

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

تكون قيمة REVERSE_PROXY_TRUSTED_PROXIES الافتراضية هي 127.0.0.0/8,::1/128، ويحدد REVERSE_PROXY_LIMIT عدد الـproxies التي ستثق بها Gitea في السلسلة. يؤدي ضبط هذا الحد على الصفر إلى تعطيل معالجة الرأس بالكامل.

يوفّر Paperless-ngx الإعداد PAPERLESS_ENABLE_HTTP_REMOTE_USER مع PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME، وتذكر وثائقه التحذير الذي يجب أن يرافق جميع هذه الإعدادات:

سيتيح ذلك المصادقة بمجرد إضافة رأس Remote-User: <username> إلى الطلب. استخدمه بحذر!

تحافظ قاعدتان على أمان المصادقة عبر الرؤوس، وكلتاهما تتعلقان بإمكانية الوصول. أولاً، يجب ألا يكون التطبيق قابلاً للوصول إلا عبر الـproxy، لأن أي شخص يستطيع فتح socket له يمكنه إرسال ذلك الرأس وتسجيل الدخول باسم أي مستخدم. في Docker، ينشر ports: ["8000:8000"] المنفذ على كل الواجهات، لذلك اربطه بعنوان loopback باستخدام ports: ["127.0.0.1:8000:8000"]، أو أزل المنفذ المنشور وضع الـproxy على شبكة Docker نفسها. ثانياً، يجب أن يحذف الـproxy أي نسخة من الرأس تصل من العميل، بحيث تكون القيمة الوحيدة التي يراها التطبيق هي القيمة التي يعيّنها الـproxy بعد المصادقة.

تحقق من الأمرين. شغّل الأمر الأول من جهاز خارج VPS، وشغّل الأمر الثاني على الخادم نفسه.

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

يجب أن يفشل curl في الاتصال، ويجب أن يطبع ss القيمة 127.0.0.1:8000 بدلاً من 0.0.0.0:8000. تعني بداية الإخراج HTTP/1.1 302 Found أن التطبيق يستجيب مباشرةً للإنترنت العام، ولذلك يمكن لأي شخص تسجيل الدخول باسم أي مستخدم عبر تحديد اسمه في رأس.

عندما لا يتوفر SSO مجاني، اتخذ قراراً بدلاً من الشكوى

أربعة خيارات، بالترتيب الذي سأجربها به.

1. اختر التطبيق الذي يتضمن OIDC. عندما يؤدي مشروعان المهمة نفسها ويتصل أحدهما بموفر الهوية لديك مجاناً، فهذا فرق حقيقي في تكلفة التشغيل.
2. استخدم forward auth بصدق. بالنسبة إلى أداة إدارية لها حساب واحد ومشغّل واحد، يكفي وضع proxy أمامها، ولن تضيف هوية كل مستخدم داخل التطبيق أي فائدة.
3. ادفع التكلفة. إذا كان التطبيق محورياً في عملك وكان السعر لكل مقعد مناسباً لحجم فريقك، فالأموال تساعد على استمرار صيانة المشروع، أما البديل فستدفع ثمنه من أمسياتك.
4. تواصل مع المشروع upstream بعد البحث في متعقّب المشكلات. وصل دعم OIDC إلى Vaultwarden من خلال fork أنشأه أحد المساهمين وpull request استمر فترة طويلة، لذلك قد يصل طلب الميزة الذي يستند إلى تنفيذ عملي إلى الإصدار المجاني أحياناً.

لا ينجح أي من ذلك من دون موفر هوية خاص بك، وهذا هو الجزء الذي ينبغي بناؤه أولاً. يوفّر لك تشغيل authentik على VPS موفر OIDC وSAML، إضافة إلى forward auth outpost المستخدم أعلاه، بينما تغطي مقارنة Keycloak وauthentik وZitadel المفاضلات إذا كنت تفضّل عدم الالتزام بأحدها بعد.

سجل التراخيص، وسبب إدراجه في قائمة التحقق

يتعلق آخر بند في قائمة التحقق بالمستقبل، لأن ترتيب التراخيص الحالي ليس سوى لقطة زمنية. وتوضح حالتان موثقتان جيداً مدى سرعة تغير الوضع، في كلا الاتجاهين. اعتمدت HashiCorp ترخيص Business Source License 1.1 لجميع الإصدارات المستقبلية في 10 August 2023، بينما بقيت الإصدارات السابقة خاضعة لترخيص MPL 2.0 (Mozilla Public License). وانتقلت Redis إلى SSPL (server side public license) في March 2024، ثم أعلنت في 1 May 2025 أن Redis 8 سيصدر أيضاً بموجب AGPLv3 (GNU Affero General Public License).

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

تحقق بنفسك من سجل المشروع قبل أن تبني عليه.

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

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

FAQ

ما المقصود بضريبة SSO؟

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

هل يُعد reverse proxy مع forward auth هو نفسه SSO؟

لا. يحمي forward auth نقطة الدخول: إذ يتحقق الـproxy من موفّر الهوية قبل وصول أي طلب إلى التطبيق. يظل التطبيق الموجود خلفه يستخدم حساباته الخاصة، لذلك إذا وصل الجميع إلى تسجيل دخول مشترك واحد، فستحصل على جلسة مجهولة واحدة وسجل تدقيق يتضمن اسماً واحداً. تصبح الهوية الفعلية لكل مستخدم متاحة فقط عندما يقرأ التطبيق اسم المستخدم من ترويسة، وهو ما يمكن أن تفعله إعدادات auth proxy في Grafana، وreverse proxy authentication في Gitea، وPAPERLESS_ENABLE_HTTP_REMOTE_USER في Paperless-ngx. تكون هذه الإعدادات آمنة فقط ما دام لا يمكن الوصول إلى التطبيق إلا عبر الـproxy، لأن الترويسة عبارة نصية عادية يمكن لأي عميل إرسالها.

ما التطبيقات ذاتية الاستضافة التي تتضمن OIDC في الإصدار المجاني؟

وفقاً للتحقق من وثائق المشاريع في August 2026، يدعم كل من Paperless-ngx وPlanka وBookStack وGitea وlistmonk وVaultwarden بروتوكول OIDC في إصداراته المجانية، كما يدرج GitLab Self-Managed بروتوكول SAML ضمن Tier: Free. يدعم الإصدار مفتوح المصدر من Grafana بروتوكول OAuth العام مع موفّر الهوية الخاص بك، بينما يُعد SAML فيه ميزة Enterprise. تحقّق من صفحة المصادقة الخاصة بالمشروع قبل التثبيت، لأن هذه القوائم تتغير مع الإصدارات.

هل ينبغي أن أدفع مقابل الفئة التي تفتح ميزة تسجيل الدخول الأحادي؟

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