يمكنك بناء نظام المصادقة الخاص بك في يوم واحد، وسيعمل لسنوات. لكن التكلفة الحقيقية تظهر لاحقًا، في اليوم الذي يتغير فيه عملك. دروس مستفادة من عشرات مقابلات B2B.
تبدو المصادقة كشيء يمكنك إنجازه بنفسك. البريد الإلكتروني، كلمة المرور، تشفيرها، المقارنة عند تسجيل الدخول. ما مدى صعوبة بناء نظام مصادقة خاص بك؟
يمكنك فعل ذلك. هذه هي الفخ.
تحدثنا مع عشرات الفرق حول أنظمة المصادقة التي بنوها بأنفسهم. معظمهم جاء إلينا لنفس السبب: كان يعوق عمل الشركة.
صناعات مختلفة، تقنيات وأحجام مختلفة، لكن نفس النهاية. أصبحت المصادقة التي بنوها عبئًا يتحمله الفريق.
الغريب في الأمر أنه لا يظهر أبدًا على شكل توقف. النظام يسمح للناس بتسجيل الدخول ويعمل بشكل جيد، حتى يحدث تغيير في العمل ويغلق الطريق: مراجعة أمنية، أول عميل مؤسسة، استحواذ، ميزة تمتد عبر منتجين.
الأسبوع الماضي كان كل شيء "جيد". ثم في اليوم التالي، تتعطل خطة العمل عند هذا الحاجز.
أكبر خطأ في المصادقة المنزلية هو اعتبارها ميزة فقط. يمكنك كتابتها في اليوم الأول. ولكن بمجرد أن يبدأ المستخدمون الفعليون بالتعامل معها، تتداخل مع المستخدمين، المؤسسات، والصلاحيات.
المصادقة ليست ميزة. إنها بنية تحتية للهوية.
كل نظام مصادقة منزلي يبدأ بنفس الطريقة: بريد إلكتروني وكلمة مرور، قم بتشفيرها، احفظها، وكرر الأمر عند تسجيل الدخول. أربعون سطرًا من التعليمات البرمجية، نظيف ومنجز.
المشاكل تبدأ بعد الإطلاق. برامج الروبوت تهاجم نقطة التسجيل، فتقوم بإضافة تحديد المعدل، كابتشا، وبصمة الجهاز. تتوقف رموز الرسائل القصيرة فجأة، فتضيف محاولات إعادة الإرسال وحدا يوميا. ثم تأتي الأجزاء الأكثر صعوبة: إعادة تعيين كلمة المرور بأمان، المصادقة متعددة العوامل وتدفق استرجاعها، الجلسات ورموز التحديث، ونموذج الصلاحيات الأكثر تعقيداً بكثير من متغير is_admin.
لا أحد من هذه الميزات صعب بمفرده. كل واحدة تناسب "سباق تطوير". لكن في كل مرة تنفذ واحدة، تجيب على سؤال أكبر نيابة عن المنتج.
عندما تجمع تلك الإجابات سويًا، تحصل على نموذج الهوية الذي يفترض منتجك الآن أنه صحيح: من يعتبر مستخدمًا، هل يمكن لشخص واحد الانتماء لأكثر من مؤسسة، كيف يتكامل نظام هوية عميل المؤسسة، وكيف يتم سحب الوصول عندما يغادر أحدهم.
كل ميزة تضيفها لاحقًا تفترض صحة تلك الإجابات، وكلما طال الزمن، أصبح من الصعب تغييرها.
رأينا هذا في إحدى الشركات: شركة SaaS رأسية في مجال B2B، لها عشرون عامًا في العمل، وتخدم مشغلي متاجر حقيقية. بنوا مصادقتهم الخاصة منذ أكثر من عقد، مع تسجيل دخول منفصل لكل عميل وفحوصات الصلاحيات مكتوبة مباشرة في وحدات الأعمال. كان القرار منطقيًا في ذلك الوقت.
بعد عشرين عامًا، أرادوا شيئًا يبدو صغيرًا: صفحة تسجيل دخول موحدة واحدة، والبريد الإلكتروني هو اسم المستخدم. لم يكن الأمر تغيير صفحة فقط. كانت تلك الفحوصات منتشرة في مئات الوحدات، وتوحيد تسجيل الدخول يعني تعديل نموذج المستخدم، نموذج المؤسسة، ترحيل بيانات الاعتماد، وكل حدود صلاحية. لم يرغب أحد في تحمل المسؤولية، فاستغرق الأمر سنوات.
عندما كتبوا أول صفحة لتسجيل الدخول، بدت كميزة. ما تركوه خلفهم كان نموذج هوية كامل.
للإنصاف، المصادقة المصنوعة منزليًا عادةً ما تعمل لفترة طويلة. تسمح للمستخدمين بالدخول، تجدد الجلسات، وتخدم العمل اليومي لسنوات. تعقيدها يتراكم ببطء، وليس دفعة واحدة، وتتعامل معه شيئاً فشيئاً وأنت تعتقد أنك تسيطر عليه.
لكن البقاء "كافيًا" غالبًا ما يعني فقط أن العمل لم يصطدم بالجدار بعد. عندما يحدث ذلك، عادة لا تكون المشكلة في المصادقة نفسها. الشركة بجوارها تغيرت، و"الكافي" يتحول بين عشية وضحاها إلى "عائق".
الحالات أدناه تظهر لدى معظم المنتجات مع نموها. يبدون مختلفين، لكن في جوهرهم نفس الشيء: العمل تقدم للأمام، ونموذج الهوية القديم لم يعد قادرًا على المواكبة.
السيناريو: يريد عميل تسجيل الدخول باستخدام موفر الهوية الخاص به، ونظام المصادقة لديك ليس لديه مفهوم "موفر هوية خارجي".
أول صفقة حقيقية مع مؤسسة تتحقق، وترسل إدارة المشتريات مستند المتطلبات. أولاً SSO عبر Microsoft Entra أو Google Workspace. ثم كلا من SAML وOIDC، لأن العميل التالي يستخدم شيئًا مختلفًا. بعدها SCIM، لتوفير الموظفين وإزالتهم تلقائيًا.
إعداد كل عميل يختلف: بروتوكولات مختلفة، خرائط حقول، تدوير الشهادات، وأسلوب ربط هيكل مؤسستهم بمؤسستك.
وقليل جدًا من هذا العمل يُعاد استخدامه. العميل التالي يجلب موفر هوية جديد وتكوين جديد، وتبدأ غالبية العمل مرارًا من جديد. SSO ليست ميزة تبنيها مرة وتكتفي. كل عميل مهم توقعه، تعيد بناءها، وتزداد التكلفة بزيادة عدد العملاء.
لم تعد المصادقة "دع المستخدمين يسجلون الدخول إلى منتجك." بل أصبحت "دع منتجك يتكامل مع نظام هوية العميل." وظيفتان مختلفتان تمامًا.
رأينا شركة يتم فيها إعداد SSO يدويًا بالكامل، ومهندس واحد فقط يفهمه من البداية للنهاية. عندما يكون متواجدًا، يعمل العملاء. عندما يأخذ إجازة، يتكدس فريق المبيعات والإعداد خلفه. وعندما يغادر، تخرج المعرفة معه.
لم يكن أي من هذا مطروحًا يوم قرروا بناء نظام المصادقة الخاص بهم.
السيناريو: بيانات الهوية بدأت مجزأة حسب المؤسسة والمنتج، ومع نمو العمل تبدأ الحاجة لهوية موحدة واحدة.
الشركة ذات العشرين عامًا أعلاه واجهت هذا عند محاولة توحيد تسجيل الدخول، ويظهر نفس النمط بين المنتجات المختلفة. عملنا مع منصة بها تسعة منتجات، جميعها من استحواذات، كل منتج يحمل نظام المصادقة الخاص به ومستودع المستخدمين الخاص به.
الاستحواذ لا يدمج هذه الأنظمة لك. كل منتج تشتريه، ترث كومة مصادقة جديدة، وتسعة أنظمة موازية تحتاج إلى موظفين فعلًا لصيانتها فقط.
الأسئلة تتراكم. هل يُعتبر الشخص نفسه مستخدمًا واحدًا عبر المنتجين A وB، أم اثنين؟ كيف تصطف نفس مؤسسة العميل في كل منتج؟ كيف تخوّل ميزة عابرة للمنتجات؟ عندما يغادر موظف، كيف يتم سحب الوصول عبر كل التسعة مرة واحدة؟ وأين ترصد أيًا من ذلك؟
ولا واحد من هذه الأنظمة التسعة معطل. لكن الجَمْعُ بينهم يشكل جداراً.
"توحيد الهوية" يبدو كميزة. لكن في الكود، يعني إعادة تعريف أهم شيء أساسي: ما الذي يعتبر مستخدمًا واحدًا ومؤسسة واحدة. تقريبًا كل ميزة تعتمد على التعريف القديم، إذن تغييره يعني تغيير كل الطبقة الفوقية.
السيناريو: لم يعد الأشخاص فقط من يسجلون الدخول عبر المتصفح. الآن الوكلاء، واجهات الأوامر، والبرمجيات النصية كلها تدعي العمل لصالح مستخدم، في حين أن مصادقتك تعرف شيئا واحدا: شخص يسجل الدخول عبر صفحة.
وكيل يحتاج لاستدعاء أدواتك الداخلية نيابة عن مستخدم. خادم MCP يحتاج لكشف موارد محمية بأمان. أداة CLI تحتاج للوصول إلى بيانات الحساب بدون متصفح.
كلهم يطرحون نفس الأسئلة: لأي مستخدم ينفذ هذا الطلب؟ ما الموارد التي يمكنه الوصول إليها؟ لمن يصدر الرمز المميز؟ ما نطاقه؟ كيف تلغيه؟ وهل تسجل المستخدم أم الوكيل؟
النظام القديم لم يبنِ الآليات اللازمة لهؤلاء العملاء. MCP يعتمد على OAuth للتفويض. أداة CLI تمر عبر تسجيل دخول OAuth أو تحمل رمز دخول شخصي بدلاً عن المستخدم ويمكن إلغاؤه في أي وقت. لم يُصمم أي من ذلك لصفحة تسجيل دخول.
إذا كان النظام مصمم فقط لشخص يسجل دخوله عبر صفحة، فهذا هو الوقت الذي عليك فيه التعامل مع عميل يمثل المستخدم.
لم ينهار المصادقة في أي الحالات أعلاه. النظام لا يزال يعمل. كل ميزة تبدو صغيرة، ولكن بمجرد البدء في تنفيذها تتحول إلى استراتيجيات المنتج، وترحيل البيانات، وتسليم متطلبات العملاء.
أوضح مثال هو MFA. على السطح هي "هل يمكننا التحقق خطوة إضافية بعد تسجيل الدخول".
بعد خطوتين، تصبح: لأي مستخدم/مؤسسة يجب فرضها؟ هل يمكن للمسؤولين فرضها للأعضاء؟ هل تتطلب الإجراءات الحساسة إعادة التحقق؟ كيف تولد وتُعيد ضبط رموز الاسترجاع؟ هل يستطيع الدعم المساعدة؟ وهل MFA الخاصة بمستخدم SSO تعود إليك أم إلى موفر هوية العميل؟ إضافة MFA تعني طبقة كاملة جديدة من سياسات الأمان.
"فقط تزامن بعض المستخدمين" لها نفس القصة: خلفها سلسلة قرارات حول الإعداد، الإخراج، وعضوية المؤسسات المتقاطعة، وكلها تفترض أن نموذج المستخدم/المؤسسة صُممت بشكل صحيح من البداية.
كلما أضفت مزيدًا من الميزات، زاد عبء صيانة منتج هوية داخل منتجك الرئيسي. النسخة الأولى رخيصة ويكفي عدد قليل من المهندسين وعدد قليل من الأسابيع. لكنها تتغذى على وقت الفريق عامًا بعد عام.
السبب الأكثر شيوعًا لبناء نظامك الخاص هو التكلفة، وليس ساذجًا.
إحدى منظمات العضوية التي أجرينا معها مقابلة حسبت الأرقام قبل خمس سنوات. كان لديها حوالي مائة ألف عضو، لكن بضعة آلاف فقط يسجلون الدخول بانتظام. كان البائعون يفرضون الرسوم اعتمادًا على عدد الأعضاء الإجمالي، فتجاوز عرض السعر الميزانية، وبناؤها بنفسها بدا أرخص. في ذلك العام لم تكن صفقة سيئة.
بعد خمس سنوات تغيرت الرياضيات. صيانة تسجيل الدخول وإبقاؤه آمنًا كلفت أكثر مما لو تم شراء حل جاهز.
في السنة الأولى، الفاتورة التي وفرتها واضحة ووقت المهندسين غير محسوب. أما في السنة الخامسة، الفاتورة الموفرة الرقم ذاته، لكن الوقت تحول إلى تأخر في خارطة الطريق، ديون أمنية، وصيانة لا يريدها أحد.
إذًا بناء المصادقة ليس مجانيًا. فقط لن تتلقى فاتورة بعنوان "اشتراك المصادقة". تدفع ذلك على شكل أشهر عمل، مواعيد نهائية فائتة، إعادة تطوير، ديون أمنية، واهتمام هندسي كان يجب أن يوجه نحو المنتج الأساسي.
المهندس الذي يصون SSO يدويًا ليس حالة فريدة. مع الزمن يتركز السياق الحرج على واحد أو اثنين: أي عميل مضبوط كيف، أي حقل لا يمكن تعديله، ولماذا تم تنفيذ ترحيل معين سابقًا. نادرًا ما يتم توثيق ذلك. يبقى فقط في أذهانهم.
عندما يكون متواجداً، يتحرك التسليم. وعندما يغيب، تتوقف الأعمال المهمة، وتكتشف أن أهم بنيتك التحتية ليس لها مالك إلا "الشخص الذي يعرف".
بعض الفرق تذهب أبعد وتبني للعملاء منصة إعداد SSO ذاتية الخدمة كاملة. تبدو ناضجة، حتى تسأل كم عميل يخدمها. رأينا نظاماً مع 1.5 مليون مستخدم نشط شهرياً يعمل بالكامل بهذه الطريقة من أجل بضعة عشرات فقط من العملاء.
كنت تعتقد أنك تبني ميزة، لكنك في الواقع كنت تبني منتجًا داخليًا وتوزع تكلفته على قلة من العملاء. إذا كانت الهوية عملك الأساسي، فهذا يناسبك. إذا لم يكن كذلك، فهي الفاتورة الخفية في أنقى صورها.
نعود إلى قصة شركة SaaS رأسية عمرها عشرون عامًا. هؤلاء ليسوا مهندسين ضعفاء. إبقاء منتج صناعي حيًا عشرين عامًا دليل على معرفتهم بعملائهم.
هذه هي المشكلة بكاملها. بصراحة: هل ترغب بأن ينشغلوا بإدارة SSO لكل عميل يدويًا واستخراج منطق الصلاحيات من مئات الوحدات على مدى عشرين سنة، أم أن يطوروا المنتج الصناعي نفسه؟
ليس هذا هوس الهندسة، بل توزيع موارد. إذا كنت تبني بوابة دفع فواتير، SaaS رأسية، بوابة عضوية، أو برنامج عمليات، فلا أحد يدفع لك فلسًا إضافيا لأنك كتبت خادم OAuth الخاص بك.
فريق بوابة دفع قابلناه قالها بوضوح: موفر الهوية المنزلي الخاص بهم جيد، لكن الأمر خيار استراتيجي. لا تكتب الكثير من الكود في المصادقة. وفر الطاقة لتحسين دفع الفواتير واجعل المصادقة من أكثر الحلول ثباتاً في السوق.
المصادقة يجب أن تكون موثوقة. لكن "موثوقة" لا تعني "كتبتها بنفسك". قاعدة بياناتك، البريد الإلكتروني السحابي، والبنية السحابية كلها يجب أن تكون موثوقة أيضا، والفريق الناضج لا يفترض أن الشيء يجب أن يكون داخليًا فقط لأنه مهم.
بالنسبة لمعظم المنتجات، المصادقة تبعية أساسية وليست ميزة فارقة. ما لم تكن الهوية عملك، لا يشكل تشغيل منتج هوية داخل منتجك الأساسي حاجزا منيعًا. بل إنها تصريف طويل الأجل للموارد.
من السهل السقوط في التطرف: لا تكتب كود مصادقة أبدًا. وهذا خطأ في حد ذاته.
في مراحل محددة، بناء مصادقتك الخاصة (أو جزء منها) أمر منطقي: تجارب داخلية، النماذج الأولية المبكرة جدًا، مشاريع تحقق لمرة واحدة. وإن كان عملك يتطلب تفويض دقيق لا تستطيع المنصات الجاهزة تلبيته، فالحفاظ عليه داخلياً مع تكليف منصة خارجية بالمصادقة، الجلسات، SSO، MFA ودليل المستخدمين هو نهج معقول تمامًا.
فقط انتبه لمنحدر إثبات المفهوم. رأينا المسار المعتاد: مطوران يقضيان ستة إلى ثمانية أشهر في نموذج أولي للاندماج مع نظام خارجي. الأسلوب ليس سيئاً. الشيء جيد حسب قولهم. فقط لم يكن معداً ليحمل عبء التوسع.
وإثبات المفهوم هو أسهل شيء يتحول إلى بنية تحتية دائمة. بعد ستة أشهر يصبح "الحل الحالي"، بعد عامين "النظام القديم"، بعد خمس سنوات "بنية لا نستطيع لمسها". أفضل وقت للخروج من المصادقة المنزلية عادة ليس بعد أن تنهار. بل قبل أن تتحول إلى الأساس.
إذًا النقطة هنا: السؤال ليس هل كتبت كود مصادقة، بل هل تحملت جزءًا عامًا من بنية الهوية التحتية وأبقيته ضمن فريقك لسنوات طويلة.
ابن الميزات النهائية بنفسك. كن حذراً في الطبقة الأساسية للهوية. ولا تبنِ دون إدراك منصة CIAM كاملة بنفسك.
إذا قررت عدم كتابتها بنفسك، يظهر السؤال التالي: أي حل تشتري، وكيف تختار؟
معظم الحلول الناضجة تملك الميزات بالفعل: SSO، MFA، مؤسسات متعددة، تسجيل دخول موحد، وصول الوكلاء. لذا الفرق الحقيقي غالبًا ليس عمود الميزات.
ما يسهل تجاوزه ويستحق المقارنة هو النقاط التالية. كلها جوانب لنقطة واحدة: لا تخرج من ألفي سطر كتبتها بنفسك لتعلق في نظام آخر لا يمكنك مغادرته.
إفصاح كامل: Logto هو منتج المصادقة الذي بنيناه وفق هذه النقاط الأربعة بالضبط. مفتوح المصدر، قابل للاستضافة الذاتية، وأيضًا متوفر كخدمة سحابية مُدارة: استخدم السحابة لصفر صيانة، أو استضف النسخة مفتوحة المصدر لتحكم كامل، ويوم تقرر المغادرة، الباب يبقى مفتوحًا.
التسجيل، MFA، SSO، وRBAC تعمل مباشرة مع OIDC القياسية، والفوترة تتبع الرموز المميزة، لذا تدفع مقابل ما تستخدم.
هناك خيارات أخرى ناضجة، ولم يكن اختيار المصادقة يومًا له إجابة صحيحة واحدة. إذا كنت تقيم الأمور، فقد كتبت مقالاً كاملاً عن كيفية اختيار حل المصادقة يمكنك الاستفادة منه.
بناء مصادقة خاصة بك غالبًا قرار منطقي في اليوم الأول. المشكلة أنها تتحول إلى بنية تحتية لاحقًا.
كل خطوة جديدة في العمل تكشف المشكلة مجددًا: المؤسسات تطلب SSO، الأمن يريد MFA، المنتج يريد تسجيل دخول موحد، منتجات متعددة يجب أن تتصل، وكلاء AI يريدون الوصول للموارد نيابة عن المستخدم. خلف كل ميزة تبدو صغيرة هناك سلسلة من سياسات معقدة، وإمدادها طيلة السنوات يستهلك وقت هندسة كان يفترض أن يصرف على منتجك الأساسي.
هذه الفاتورة لا تصل في اليوم الأول. عادة تصل بعد سنوات. عندها فقط تراها: صفحة تسجيل الدخول التي كتبتها سابقًا كانت بنية تحتية للهوية ستبقى طوال عمر المنتج.
على الأرجح المصادقة ليست عملك الأساسي. كلما أدركت ذلك أسرع، أعدت وقتك وطاقة فريقك ومواردك إلى المنتج الذي تبنيه فعلاً.
لا. تجارب مبكرة، أدوات داخلية، مشاريع تحقق لمرة واحدة، أو تفويض معقد جدًا لا تستطيع الخيارات الجاهزة تلبيته كلها مناسبات ممكنة. ما يجب تجنبه هو تحمل جزء بنية الهوية العامة لفترة طويلة دون انتباه وتركه ضمن مسؤولية فريق العمل الدائم.
المصادقة تجيب "من أنت". التفويض يجيب "ماذا يمكنك أن تفعل". في SaaS الحقيقي يصعب الفصل بينهما: المستخدمون، المؤسسات، الأدوار، الصلاحيات، الجلسات، بيانات الرموز وسجلات التدقيق كلها متشابكة. لذا عند استبدال نظام مصادقة، لا تستطيع النظر فقط إلى صفحة تسجيل الدخول.
لأنه يعني جعل منتجك يتكامل مع نظام هوية العميل نفسه. العملاء المختلفون يستخدمون موفري هوية وبروتوكولات وحقول بيانات وشهادات وخرائط هيكل مؤسسي مختلفة. ربط أول عميل لا يعني أن البقية نسخ-ولصق. غالبًا تصبح العملية يدوية لا يفهمها سوى مهندس واحد.
نعم، لكن القطع الكامل عادة ليس الحل. ابدأ الترحيل تدريجيًا: اجعل التسجيلات الجديدة وتسجيل الدخول وSSO للشركات على منصة الهوية، وهاجر المستخدمين الحاليين عند تسجيلهم التالي. حافظ على مسار تراجع وسجلات تدقيق طوال الوقت حتى لا يصبح الترحيل غير قابل للعكس.