يمكنك بناء مصادقتك الخاصة في يوم واحد. هذه هي الفخ.
عدد من فرق B2B أخبرونا نفس القصة. تبدأ بصفحة تسجيل دخول بسيطة. ثم يبدأ استخدام جدي عليها، وتتحول بهدوء إلى بنية تحتية للهوية: الأساس الذي يقوم عليه منتجك بالكامل.
بدت كميزة واحدة. لكن تركت وراءها نموذج هوية كامل.
كل نظام مصادقة منزلي يبدأ بعدد قليل من الأسطر البرمجية. المشاكل تظهر بعد الإطلاق، عندما تصبح كل قرار صغير فجأة جزءًا من النموذج الذي يفترض به منتجك بأكمله.
اليوم الأول: أربعون سطرًا من الكود
بريد إلكتروني، كلمة مرور، تشفير، تخزين، مقارنة عند تسجيل الدخول. سهل ومنجز.
اليوم المئتان: نموذج هوية صامت
من يُعد مستخدمًا؟ لأي منظمة ينتمي؟ ما هي الجلسة التي لا تزال موثوقة؟ كيف يتم سحب الصلاحيات؟
السنة الخامسة: أساس لا يمكنك لمسه
استبدال صفحة تسجيل الدخول نظريًا يعني إعادة بناء البنية التحتية للهوية في الكود.
المصادقة المنزلية تعمل بشكل جيد — حتى يتغير العمل
تسجّل المستخدمين لسنوات بدون مشاكل. ثم يحدث تغيير في العمل يجعل "كافي" يتحول إلى "عائق" بين ليلة وضحاها. هذه الحالات الثلاث تظهر تقريبًا في كل منتج يتوسع.
العملاء المؤسساتيون يبدؤون بالطلب تسجيل الدخول الموحد (SSO)
تحصل على أول صفقة كبيرة ويريد فريق التوريد SSO من خلال Entra أو Google Workspace الخاص بهم. ثم يطلبون SAML و OIDC معًا، لأن العميل التالي يستخدم حلاً مختلفًا. إعداد الهوية يختلف من عميل لآخر، وتقريبًا لا يوجد عمل يمكن إعادة استخدامه.
- بروتوكولات، حقول بيانات، ودوران شهادات مختلف لكل عميل
- تسجيل الدخول الموحد لا يُبنى مرة واحدة. عليك إعادة بنائه لكل مؤسسة تتعاقد معها
- يصبح عمل يدوي يفهمه مهندس واحد فقط من البداية للنهاية
هوية بدأت مشتتة يجب أن تصبح واحدة
مقسمة حسب المنظمة، مقسمة حسب المنتج، وغالبًا موروثة من الاستحواذات. “توحيد الهوية” قد يبدو ميزة، لكنه في البرمجة يعني إعادة تعريف من هو المستخدم وما هي المنظمة.
- هل يمكن لبريد إلكتروني واحد أن ينتمي لعدة منظمات؟ كيف تهاجر أسماء المستخدمين القديمة؟
- تسعة منتجات من الاستحواذات تعني تسعة أنظمة مصادقة تعمل بالتوازي
- إلغاء صلاحية موظف سابق في جميع هذه الأنظمة مرة واحدة وتدقيق ذلك من مكان واحد
وكلاء الذكاء الاصطناعي وCLI تبدأ بالتصرف نيابًة عن المستخدم
لم يعد الأمر يقتصر على الأشخاص في المتصفح. عملاء، خوادم MCP، وخطوط الأوامر جميعها تدّعي العمل بالنيابة عن مستخدم. ونظام المصادقة لديك يعرف فقط كيف يسمح لشخص بالدخول عبر صفحة.
- لمن تم إصدار الرمز؟ ما هو النطاق والجهة المستلمة؟
- امنح أداة واحدة أو جزءًا واحدًا من البيانات، ثم قم بإلغائه لاحقًا
- الوصول عبر MCP وCLI يعتمد على OAuth وليس على نموذج تسجيل دخول
التكلفة الحقيقية ليست في البناء. بل في الحفاظ عليه لسنوات.
الإصدار الأول رخيص: بعض المهندسين، بضعة أسابيع، ويكون جاهزًا. لكن ستستهلك منه سنويًا الساعات الهندسية التي كان من المفترض أن تذهب لمنتجك الأساسي.
الفاتورة لم تختف بل تغيرت طريقة دفعها
لن تتلقى فاتورة تقول "المصادقة".
يعتمد في صمته على شخص أو شخصين فقط
السياق الحرج موجود في رأس شخص ما وليس في التوثيق.
أين تفضل توظيف مهندسيك؟
لا أحد من العملاء سيدفع لك فلسا إضافيا لأنك كتبت خادم OAuth بنفسك.
إذا لم تبنيه بنفسك، كيف تختار؟
الأنظمة الناضجة تغطي فعليًا جميع الميزات: SSO، MFA، المنظمات، دخول موحد، وصول الوكلاء. الفرق الحقيقي يكمن في إمكانية المغادرة. لا تترك بضع آلاف من الأسطر لتقع في أسر نظام مغلق آخر.
بروتوكولات قياسية، لا بنية مخترعة
باب يمكنك الخروج منه فعلًا
الفوترة لا تتتبع جدول المستخدمين
بياناتك ليست محبوسة أبدًا
من المحتمل أن المصادقة ليست عملك الأساسي. عاملها على هذا الأساس.
Logto مفتوح المصدر، قابل للاستضافة الذاتية، ويُقدم أيضًا كخدمة سحابية مدارة. تسجيل الدخول، MFA، SSO، والتحكم في الصلاحيات (RBAC) تعمل مباشرة مع OIDC القياسي. الفوترة تعتمد على الرموز، وعندما تقرر المغادرة، الباب مفتوح.