كيفية اختيار مزود الهوية: إطار تقييم فريق الهندسة

معظم المقالات التي تقارن مزودي الهوية مكتوبة من قبل مزودي الهوية أنفسهم. صادم، أليس كذلك؟ يذكرون الميزات التي تقدمها منتجاتهم، ويتجاهلون الميزات التي لا توفرها، ويسمونها "دليل موضوعي".

هذا الدليل مختلف.

لقد قمنا بمراجعة عشرات الطلبات الفعلية لتقييم المؤسسات — الجداول والوثائق الحقيقية (RFP) التي ترسلها فرق الشراء للبائعين. النمط واضح: فرق الهندسة تضع وزناً أقل للمعايير الأهم ووزناً أعلى للمعايير الأقل أهمية.

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

إليك إطار التقييم الذي تمنينا لو أعطانا أحد إياه عندما بدأنا. تم تصميمه لفرق الهندسة في شركات B2B SaaS — التي تبني المنتجات، وليس تلك التي تشتري SSO لموظفيها.

الجواب السريع: ما الذي يُنجح أو يُفشل قرار اختيار IdP#

إذا كنت تتصفح بسرعة، فإليك النسخة المختصرة:

1. عمق البروتوكول أهم من عدد الميزات. مجرد دعم "OAuth2" لا يعني شيئاً. ما هي أنواع المنح المدعومة؟ هل يمكنك تخصيص مطالبات الرموز؟ هل تستطيع أن تصبح مزود OIDC بنفسك؟
2. قدرة الهجرة هي المعيار الأكثر تقليلاً من قيمته. إذا لم تستطع ترحيل مستخدميك الحاليين بدون فرض إعادة تعيين كلمات المرور، فإن IdP غير مجدي — بغض النظر عن جودة كل شيء آخر.
3. تعدد المستأجرين يجب أن يكون أصيلاً، وليس إضافة سطحية. إذا كانت نماذج المؤسسات وإعدادات كل مستأجر تحتاج إلى حلول مؤقتة، فسوف تقاتل النظام إلى الأبد.
4. الاستعداد للذكاء الاصطناعي ليس تخطيطاً للمستقبل — بل متطلب في غضون 12 شهراً. تبادل الرموز، هوية العميل، التفويض المندوب. إذا لم يدعم IdP هذه الأمور، ستعود هنا للتقييم مرة أخرى السنة القادمة.

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

من هو المستهدف بهذا الدليل (ومن ليس مستهدفاً)#

هذا الدليل لك إذا:

• أنت مدير تقني (CTO)، نائب رئيس للهندسة، أو مهندس منصة في شركة B2B SaaS تضم 50-300 شخص
• لديك أكثر من 100,000 مستخدم حالي ولا يمكنك تحمل هجرة تضر المستخدمين
• تتجه نحو عملاء المؤسسات الذين يحتاجون SSO، ونماذج مؤسسات، وسجلات تدقيق
• تحتاج إلى كتابة تقرير تقييم تقني وتريد إطاراً لا يأتي من البائعين

هذا الدليل ليس لك إذا:

• تبحث عن IAM خاص بالموظفين (SSO لأدوات داخلية) — هذا قرار شراء مختلف
• شركة ناشئة بعدد 500 مستخدم ولا توجد لديك عملاء مؤسسات بعد — اختر ما توفر أفضل SDK وانطلق
• تحتاج إلى التحقق من الهوية (KYC/KYB) — هذا تصنيف منفصل تماماً

البعد 1: قدرات البروتوكول — ليس مجرد "دعم OAuth2"#

كل IdP في السوق سيخبرك أنه يدعم OAuth2 وOIDC. هذا أدنى مستوى مقبول. الأسئلة الحقيقية تتعلق بالعمق.

أنواع المنح: أيها ولماذا الأهمية؟#

أساسي:

• رمز التفويض + PKCE — التدفق الوحيد الذي يجب استخدامه لتطبيقات الويب والموبايل. إذا كان البائع لا يزال يوصي بتدفق Implicit، تغادر فوراً. PKCE ليست اختيارية — بل مطلب أمني.
• بيانات اعتماد العميل — للتواصل من خدمة إلى خدمة. خدماتك الخلفية تحتاج للمصادقة مع بعضها دون وجود مستخدم.
• رمز التحديث — تبدو أساسية، لكن تفاصيل التنفيذ تختلف كثيراً. هل يمكنك ضبط التدوير؟ فترة الصلاحية؟ هل يمكنك إبطال رمز تحديث واحد فقط بدون إنهاء الجلسة كلها؟

أصبحت حرجة بشكل متزايد:

• تبادل الرموز (RFC 8693) — هذا النوع من المنح يمكّن المصادقة للعميل الذكي (الذكاء الاصطناعي)، تدفقات التقمص، والتفويض. إذا كان مفقودًا اليوم، اسأل عن خارطة الطريق. إذا لم تكن هناك خطة، هذه إشارة حمراء.

قدرة مزود OIDC#

هناك سؤال لا تفكر فيه معظم الفرق: هل يمكنك استخدام هذا IdP كمزوّد OIDC — وليس فقط كمستهلك OIDC؟

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

اسأل:

• هل يوفر الـ IdP نقطة اكتشاف OpenID يمكن تقديمها بهويتك؟
• هل يمكنك تسجيل تطبيقات مسجلة من طرفك وأخرى من طرف ثالث بمستويات ثقة مختلفة؟
• هل يمكن تخطي شاشة الموافقة للتطبيقات المسجلة بينما يطلبها للطرف الثالث؟

تخصيص JWT#

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

اسأل:

• هل يمكنك إضافة مطالبات مخصصة على رموز الولوج ورموز الهوية؟
• هل يمكنك تضمين سياق المؤسسة (أي مستأجر يعمل فيه المستخدم) داخل الرمز مباشرة؟
• هل يمكنك تعريف صلاحيات مخصصة (scopes) تناسب نموذج الصلاحيات لتطبيقك؟
• هل تُحتسب المطالبات عند إصدار الرمز أو يمكن احتسابها آنيًا عبر webhook أو نص برمجي؟

رمز يحمل { "org_id": "org_123", "role": "admin", "auth_level": 2 } يعني أن الوسيط البرمجي لواجهتك يستطيع اتخاذ قرار التفويض بسطر واحد. رمز يحمل فقط { "sub": "user_456" } يعني أن كل خدمة تحتاج للاتصال بـ IdP أو قاعدة بيانات للحصول على البقية. على نطاق واسع، الفرق بين هذا وذاك هو ٢ ميللي ثانية مقابل ٢٠٠ ميللي ثانية لكل طلب.

البعد 2: تدفقات المصادقة — التفاصيل التي تؤذيك#

كل IdP يدعم البريد الإلكتروني/كلمة المرور وتسجيل الدخول الاجتماعي. تهانينا، لقد قلصت الخيارات إلى... جميعهم.

الاختلاف في التفاصيل التي لا تغطيها معظم العروض التوضيحية.

تدفق التسجيل#

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

تدفق تسجيل الدخول#

• دعم login_hint: عند نقر المستخدم على رابط من بريد تسويقي، هل يمكنك تعبئة بريده تلقائياً؟ تبدو تافهة. ليست كذلك. الفرق بينها وبين عدمها قد يصل إلى ٤٠٪ مقابل ٦٠٪ معدل تحويل لحملات البريد.
• سياسات مصادقة خاصة بالمؤسسة: هل يمكن أن تطلب المنظمة A SAML SSO بينما المنظمة B تستخدم البريد وكلمة المرور؟ هل يمكنك فرض MFA لكبار العملاء فقط؟ إذا كانت سياسات المصادقة لكل مستأجر تتطلب تغيير كود، ستخسر وقتًا هندسيًا كل مرة تضيف عميلاً مؤسسياً.
• تخصيص العلامة التجارية: هل يمكنك تخصيص تجربة تسجيل الدخول لكل مستأجر؟ ليس مجرد الشعار والألوان — بل التحكم الكامل في CSS، النطاقات المخصصة، رسائل البريد المسماة. يجب أن يكون "واجهة مستضافة أو خاصة" خياراً لا قيدًا.

ما تتجاهله معظم قوائم الفحص#

• المصادقة الصامتة: عند انتهاء صلاحية الرمز، هل يمكن أن يحدث التحديث دون إعادة توجيه المستخدم؟ ماذا إذا انتهت صلاحية رمز التحديث أيضاً — هل هناك حل احتياطي (جلسة متزلقة عبر iframe)؟
• ربط الحسابات: مستخدم يسجل بجوجل ثم يحاول الدخول بالبريد. هل هما حسابان أم حساب واحد؟ كيف يتعامل IdP مع دمج الهوية؟ إذا أخطأت هنا ستجد حسابات مكررة للأبد.
• خيارات بلا كلمة مرور: روابط سحرية، مفاتيح المرور، WebAuthn. ليس لأن الجميع يحتاجها الآن، لكن لأن عملاء الشركات سيطلبونها خلال ٦ أشهر.

البعد 3: إدارة الجلسات والرموز — العمق الحقيقي#

هنا تنفصل التقييمات عن العروض التوضيحية. إدارة الجلسات والرموز مملة حتى تنهار — وعندما تنهار يخرج كل مستخدميك دفعة واحدة.

أمان الكوكيز#

ليست براقة. لكنها بالغة الأهمية.

• سمات HttpOnly, Secure, SameSite: يجب تعيين الثلاثة بشكل صحي. أي IdP لا يفعل HttpOnly على كوكي الجلسة غير جاهز للإنتاج.
• دعم تعدد النطاقات الفرعية: إذا كان تطبيقك يعمل على app.yourproduct.com وواجهة API على api.yourproduct.com، هل يمكن للجلسات أن تشمل كلا النطاقين؟ كيف؟
• إيقاف دعم كوكي الطرف الثالث: كروم سيوقف هذا. كيف يدير IdP تدفق المصادقة عبر النطاقات دون كوكي الطرف الثالث؟ إذا قال "نعمل عليها" فهذا غير كافٍ.

تذكرني والجلسات الدائمة#

يريد المستخدمون البقاء مسجلين لأسابيع، لا دقائق. لكن جلسة دائمة لـ180 يوم تختلف أمنياً كثيرًا عن جلسة ٣٠ دقيقة.

اسأل:

• هل يمكنك ضبط مدة الجلسة مستقلة عن مدة صلاحية الرمز؟
• هل هناك خيار "تذكرني" يطيل الجلسة دون تمديد عمر الرمز؟
• هل يمكنك طلب إعادة المصادقة للعمليات الحساسة دون إنهاء الجلسة؟

أمان رمز التحديث#

• تدوير الرموز: هل يقوم IdP بتدوير رمز التحديث في كل استخدام؟ (يجب أن يفعل ذلك.)
• تخزين مشفر: هل يتم تشفير رموز التحديث أثناء السكون؟
• تفصيل الإلغاء: هل يمكنك إلغاء جلسة جهاز واحد دون إلغاء كل الجلسات؟
• صلاحية مخصصة: التطبيقات المختلفة بحاجة لعمر رمز تحديث مختلف. هل يمكنك ضبط هذا لكل تطبيق، أم هو إعداد عام؟

البعد 4: نموذج التفويض — ما بعد RBAC الأساسي#

التحكم المعتمد على الدور (RBAC) هو الأساسي. إذا لم يدعم IdP ذلك، لا يستحق التقييم. لكن في B2B SaaS، RBAC وحده لا يكفي.

صلاحيات ضمن المؤسسة#

مستخدموك ينتمون إلى مؤسسات. صلاحياتهم داخل كل مؤسسة تختلف عن صلاحياتهم على مستوى المنصة.

قد يكون المستخدم مشرفًا في المنظمة A ومشاهدًا في المنظمة B. نفس المستخدم، سياقين من الدور. إذا لم يكن IdP يمكنه نمذجة ذلك أصيلاً، ستبني نظام صلاحيات موازٍ داخل تطبيقك — وحينها لديك مصدران للحقيقة.

أسئلة:

• هل يمكنك تعريف الأدوار على مستوى المؤسسة وليس مجرد المستخدم؟
• هل يمكن لمستخدم واحد الحصول على أدوار مختلفة في مؤسسات مختلفة؟
• هل يتم تضمين سياق المؤسسة الحالي داخل الرمز بحيث يعرف API لأي منظمة يتبع الطلب؟

تفويض متعدد المستويات (auth_level)#

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

مشاهدة لوحة تحكم؟ كوكي الجلسة يكفي. إجراء تحويل أموال؟ تحتاج تحقق MFA جديد—even لو كان المستخدم مسجلًا الدخول.

هذه هي المصادقة المتدرجة (step-up) وتحتاج مفهوم مستوى المصادقة (auth_level) كجزء أصيل في نظام الرموز.

اسأل:

• هل يمكن للرمز أن يحمل مطالبة auth_level يمكن للباك إند فحصها؟
• هل يمكنك تفعيل المصادقة المتدرجة من تطبيقك دون إجبار المستخدم على إعادة الدخول بالكامل؟
• هل لـ auth_level صلاحية انتهاء خاصة، مستقلة عن الجلسة؟

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

تفويض قائم على الرمز#

الوضع المثالي: وسيط API يقرأ الرمز، يرى المؤسسة والدور ومستوى المصادقة، ويتخذ قرار التفويض مباشرة بلا استدعاء خارجي.

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

تلك المكالمة تضيف زمن تأخير، وتخلق اعتمادًا، وتدخل حالة فشل. مع 1000 طلب بالثانية لا تريد أن تحقق التفويض عن طريق الشبكة.

البعد 5: الهجرة — المعيار الحاسم#

ثمة إحصائية لا يحب أحد ذكرها: معظم تقييمات IdP تنتهي ليس لأن IdP الجديد غير كاف، بل لأن الفريق لا يعرف كيف يهاجر مستخدميه الحاليين.

لو لديك 100,000+ مستخدم، الهجرة ليست "ميزة لطيفة" — بل هي المشروع كله.

ثلاث استراتيجيات للهجرة (وأيها يجب أن يدعمها IdP)#

1. الاستيراد بالجملة مع كلمات المرور المشفرة الحالية

لدى المستخدمين كلمات مرور مشفرة بـ bcrypt أو argon2 أو أي خوارزمية لديك. هل يمكن لـ IdP استقبال تلك الشفرات والتحقق منها مباشرة؟

إذا نعم: يدخل المستخدمون بكلماتهم الحالية ولا يشعرون بفارق. أفضل سيناريو.

إذا لا: يحصل الجميع على بريد "أعد تعيين كلمة المرور". ستخسر 30–50٪ من قاعدة المستخدمين أثناء الهجرة. ليست افتراضية — بل واقعية.

2. الهجرة التدريجية (الكسولة)

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

هذه الطريقة الأكثر أمانًا للقواعد الكبيرة، لكن تحتاج أن يدعم IdP:

• خطاف مصادقة مخصص يتحقق من النظام القديم
• إمكانية إنشاء مستخدمين فوريًا أثناء تسجيل الدخول
• تتبع من تم ترحيله ومن لم يتم

3. الكتابة المتوازية (أنظمة متزامنة)

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

إشارات حمراء للهجرة#

• "ندعم الاستيراد عبر CSV" — هذا يعني استيراد بيانات المستخدم، وليس كلمات السر. ستظل بحاجة لإعادة تعيين كلمات السر.
• "لدينا دليل هجرة" — اقرأ بعناية. إذا ذكر أن "على المستخدمين تعيين كلمة سر جديدة"، هذا سيناريو فقدان 30–50٪ من المستخدمين.
• بلا ذكر توافق الشيفرة — إذا لم يذكر البائع شيفرة كلمات المرور، لم يتعامل مع قواعد بحجمك.

أسئلة يجب طرحها#

• ما خوارزميات تشفير كلمات المرور المدعومة للاستيراد؟ (bcrypt, argon2, scrypt, PBKDF2, مخصص؟)
• هل يمكننا إجراء هجرة تدريجية حيث يُرحّل المستخدم عند أول تسجيل دخول؟
• هل يمكن تتبع تقدم الهجرة — ما نسبة من تم ترحيلهم؟
• ما استراتيجية التراجع إذا لم تكن الهجرة سلسة؟
• هل يمكن الحفاظ على استمرار الجلسات — بحيث لا يخرج المستخدمون أثناء الهجرة؟

إذا لم يجب البائع بثقة، لم يفعل ذلك من قبل. واصل البحث.

البعد 6: تعدد المستأجرين — أصيل أم سطحي؟#

B2B SaaS يعني تعدد المستأجرين. عملاؤك مؤسسات ذات عدة مستخدمين، أدوار وسياسات وصول. يجب على IdP أن يفهم ذلك أصيلاً.

ماذا يعني "تعدد مستأجرين أصيل"#

• المؤسسة كعنصر رئيسي: ليست حقلاً مخصصاً في الملف الشخصي، بل نموذج بيانات حقيقي له معرفه الخاص، إعداداته وقائمة أعضائه.
• سياسات مصادقة لكل مؤسسة: المنظمة A تستخدم SAML SSO مع IdP خاص بهم. B تستخدم البريد مع MFA إجباري. C تستخدم جوجل. كل ذلك بالإعدادات لا الكود.
• دعوات المؤسسة وإدارة الأعضاء: مديرو المؤسسة يمكنهم دعوة أعضاء، تعيين الأدوار، وحذف الأعضاء. يدير IdP سير الدعوة والتحقق من البريد وتعيين الدور.
• رموز ضمن المؤسسة: حين يعمل المستخدم ضمن مؤسسة، يحمل الرمز سياق المنظمة. الـ API لديك يعرف لأي بيانات يجب الرد.

الحل البديل "بيانات التعريف المخصصة"#

بعض IdP لا توفر نموذج مؤسسة أصيل. يقترحون استخدام metadata (user.app_metadata.org_id = "123") كحل.

ينهار هذا سريعاً:

• مستخدم في عدة منظمات يتطلب مصفوفة metadata
• لا سير دعوة أو إدارة أعضاء
• لا سياسات مصادقة حسب المؤسسة
• لا رموز منظمة — يجب أن تستنتج السياق
• لا سجلات تدقيق تعرف عن المؤسسات

إذا قال البائع "يمكنك نمذجة المؤسسات عبر metadata"، فهذا مثل تخزين البيانات العلائقية في JSON. يعمل... حتى يفشل.

أسئلة يجب طرحها#

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

البعد 7: الاستعداد للذكاء الاصطناعي — المعيار الذي لم يسأل عنه أحد بعد#

منذ 12 شهرًا، لم يكن هناك في قوائم التقييم شيء اسمه "مصادقة وكلاء الذكاء الاصطناعي". اليوم، إذا كنت تبني ميزات AI في منتجك — مساعدين، وكلاء مستقلين، سير العمل بالذكاء الاصطناعي — يحتاج IdP لمعالجة هوية من نوع جديد: العميل.

لماذا العملاء يكسرون النموذج التقليدي#

المصادقة التقليدية فيها طرفين: المستخدم والتطبيق. OAuth2 صمم لهذا.

وكلاء الذكاء الاصطناعي (العملاء) يدخلون طرفًا ثالثًا: كيان غير بشري يعمل نيابة عن المستخدم، ذات صلاحيات مقيدة وسجل تدقيق خاص.

• العميل ليس مستخدمًا — لا كلمة مرور ولا جلسة متصفح
• العميل ليس خدمة آلية صرفة — بل يعمل نيابة عن مستخدم محدد
• العميل يحتاج لصلاحيات محددة بزمن — لا كل الصلاحيات

ما الذي يجب أن يدعمه IdP هنا#

Token Exchange (RFC 8693): يقدم العميل أوراقه بجانب تفويض المستخدم ويستقبل رمز بصلاحيات محددة. يحمل من (المستخدم)، ماذا (العميل)، مدى الصلاحية، ووقت الانتهاء.

عميل كنموذج OAuth2: يجب أن يكون العميل OAuth2 client بمعرفه الخاص، لا مجرد مفتاح API أو رمز مستخدم مشترك.

إدارة صلاحيات مندوَبة: يمكن للمستخدم منح صلاحيات معينة للعميل — قراءة بدون كتابة، موارد محددة دون الأخرى.

تمييز في السجلات: يجب أن تفرق سجلاتك بين "المستخدم قام بـX" و"العميل قام بـX نيابة عن المستخدم". إذا لم تميز ذلك، ستفشل تدقيق SOC2 القادم حين يسأل المدقق "من نفذ هذا التغيير؟"

توافق MCP (بروتوكول سياق النموذج)#

MCP بات معيارًا لوكلاء الذكاء الاصطناعي للتفاعل مع الأدوات والخدمات. إذا كان IdP يدعم المصادقة عبر OAuth لـ MCP، يستطيع العملاء المصادقة بالشكل الصحيح عبر طبقة البروتوكول بدل مفاتيح أو أسرار مشتركة.

أسئلة يجب طرحها#

• هل تدعم Token Exchange عبر OAuth2؟
• هل يمكن نمذجة العملاء كنوع منفصل من OAuth2 client؟
• هل يمكن للرمز حمل معلومات التفويض (من فوض، وما الصلاحيات)؟
• هل تميز سجلات التدقيق بين أفعال العملاء والبشر؟
• هل يوجد تكامل MCP أو دعم OAuth لمصادقة العملاء للأدوات؟

إذا لم يفكر البائع بهذا، يبني لعام 2020. وأنت تخطط لعام 2026.

البعد 8: المتطلبات غير الوظيفية — الأمور التي تمنعك من النوم#

الميزات تبيع. العمليات تحدد ما إذا كنت ستجدد.

الأداء#

• معدل المصادقة: هل يمكن للنظام دعم 100+ طلب مصادقة في الثانية أثناء الذروة؟ وماذا عن 1000+؟
• زمن تحقق الرمز: إذا كانت خدماتك تتحقق من JWT محليًا (وينبغي ذلك) فهذا دون الميللي ثانية. لكن إذا تطلب IdP اتصال التحقق، كم زمن P99؟
• سقف التوسع: ما الحد الأقصى للمستخدمين النشطين شهريًا المدعومين؟ هل هناك سجل نجاح عند حجمك المستهدف؟

الامتثال#

• SOC2 نوع II: ليس نوع I فقط. النوع الثاني يعني التدقيق عبر فترة وليس مجرد لحظة. إذا كان لديهم النوع الأول فقط، اسأل عن موعد النوع الثاني.
• سجلات التدقيق: كل حدث مصادقة، تغيير صلاحيات، وتصرّف إداري مسجل. هل يمكنك تصدير السجلات لـ SIEM؟ هل هي سجلات غير قابلة للتغيير؟
• إقامة البيانات: هل تستطيع تحديد أي منطقة يخزن فيها بيانات المستخدمين؟ للعملاء في الاتحاد الأوروبي هذا إلزامي.

الموثوقية#

• اتفاقية مستوى الخدمة (SLA) لمدة التشغيل: 99.9% تبدو جيدة حتى تعرف أنها تعني 8.7 ساعات توقف سنويًا. 99.99% تعني 52 دقيقة. للمصادقة — باب الدخول لمنتجك — الفرق مهم.
• خطط التبديل: ماذا يحدث أثناء انقطاع مقدم الخدمة؟ هل هناك مسار طوارئ؟ نشر متعدد المناطق؟
• تاريخ الحوادث: افحص تاريخ صفحة الحالات لديهم. ليس ما يعدون به — بل ما حدث فعلاً.

قابلية نقل البيانات#

• تصدير المستخدمين: هل يمكن تصدير كل بيانات المستخدمين، بما فيها metadata، العضويات والصلاحيات؟ بأي صيغة؟
• مطابقة المعايير: هل يستخدمون بروتوكولات معيارية (OIDC، SCIM) لتسهيل الانتقال لمزود آخر؟
• إشارات عدم الإغلاق: واجهات خاصة، بروتوكولات مخصصة، رموز غير معيارية — هذه إشارات إغلاق. كلما كثر التخصيص، زادت صعوبة المغادرة.

مصفوفة التقييم: إطار النقاط العملي#

بعد التقييم في كل بُعد، تحتاج طريقة للمقارنة. إليك إطار الأولوية:

P1 — كاسر للصفقة (من يفشل يُستبعد)#

P2 — مفضل بشدة (جهد هندسي ضخم إن غاب)#

P3 — مهم (خلال 12 شهرًا)#

P4 — كماليات (لا يعيق القرار)#

كيفية استخدام هذا: ابدأ بـP1. إذا فشل البائع بأي معيار P1 توقف التقييم. ثم قيّم معايير P2 وP3. البائع الذي يحصل على أعلى مجموع في P2+P3 هو اختيارك.

أخطاء التقييم الشائعة#

رأينا الفرق تكرر نفس الأخطاء. إليك كيف تتجنبها:

الخطأ 1: التقييم حسب الميزات، لا الهندسة#

جدول ميزات يخبِرك ما الموجود، لكنه لا يخبِرك كيف بني. ربما يدعم IdP المؤسسات بوضع معرف المؤسسة في metadata. يبدو ضمن القائمة لكنه يخلق مشاكل حقيقية إنتاجيًا.

الحل: لكل ميزة، اسأل "كيف بنيت؟" وليس فقط "هل لديك هذا؟"

الخطأ 2: تجاهل الهجرة حتى بعد الاختيار#

تختار الفرق IdP "الأفضل"، تبدأ التنفيذ، ثم تكتشف عدم القدرة على ترحيل المستخدمين دون حملة إعادة تعيين كلمات المرور. الآن أمام خيارين: تجربة هجرة سيئة أو البدء من جديد.

الحل: اجعل قدرة الهجرة مرشحك الأول لا الأخير.

الخطأ 3: المبالغة في الاهتمام بالعرض التوضيحي#

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

الحل: اطلب نموذج إثبات مفهوم ببياناتك الفعلية. استورد ١٠٠٠ مستخدم فعلي، ونفّذ تدفقات المصادقة الحقيقية.

الخطأ 4: عدم إشراك الأشخاص المناسبين#

إذا قيّم فريق المنصة وحده اختار الأنظف تقنياً. إذا قيّم المنتج فقط اختار الأسهل دمجاً. إذا قيّم الأمن فقط اختار الأكثر امتثالاً.

الحل: فريق التقييم يجب أن يشمل هندسة المنصة، المنتج، والأمان. كل منهم مسؤول عن معايير P1/P2 مختلفة.

الخطأ 5: نسيان أنك ستضطر للرحيل يومًا ما#

الإغلاق مع البائع حقيقي. SDKs خاصة، APIs مخصصة، رموز غير قياسية — جميعها تجعل الهجرة لاحقاً أصعب.

الحل: فضل IdP الذي يستخدم بروتوكولات قياسية (OIDC, OAuth2, SCIM). مستقبلك سيشكرك.

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

كم تستغرق عادةً عملية تقييم IdP؟#

لتقييم شامل مع اختبار إثبات المفهوم، جهز من ٤–٨ أسابيع. الاستعجال يؤدي للأخطاء أعلاه — خاصة تجاهل الهجرة. خصص أسبوعين لجمع المتطلبات، ٢–٣ أسابيع لتقييم البائعين وإثبات المفهوم، و١–٢ أسبوع لاتفاق المعنيين.

هل يجب أن نبني المصادقة بأنفسنا؟#

يعتمد على المرحلة. إذا كان لديك أقل من ١٠ آلاف مستخدم، ولا عملاء شركات، مكتبة مصادقة بسيطة قد تفي بالغرض. لكن فور الحاجة لـSSO، تعدد مستأجرين، MFA، وتوثيقات الامتثال فتكلفة الصيانة تفوق IdP جاهز. رأينا فرق هندسة كاملة تصرف راتب ٢–٣ موظفين بدوام كامل للصيانة — أي ٣٠٠-٥٠٠ ألف دولار سنويًا.

ما الفرق بين CIAM وworkforce IAM؟#

CIAM (إدارة هوية العملاء) يتفاعل معه المستخدمون النهائيون لمنتجك — تسجيل، دخول، إدارة بروفايل. workforce IAM لموظفيك لدخول الأدوات الداخلية (Okta لـ Slack الشركة، Google Workspace ...إلخ). قرارا شراء وتقييم منفصلان. هذا الدليل حول CIAM.

ما أهمية كون IdP مفتوح المصدر أم خاص؟#

المفتوح يعطي شفافية (مراجعة الشيفرة)، قابلية النقل (تستضيف ذاتياً إن شئت)، مساهمات المجتمع. IdP الخاص قد يقدم واجهات مصقولة وخدمات مدارة. السؤال الأهم ليس "مفتوح أم مغلق" — بل "هل أستطيع المغادرة؟" الحلول مفتوحة المصدر تسهل المغادرة لأن النموذج وAPIs علنية.

متى يجب أن تصبح مصادقة العملاء الذكائيين P1 بدل P3؟#

إذا كنت تبني بالفعل ميزات ذكاء اصطناعي تصل لبيانات المستخدم، اجعلها P1 الآن. إذا كانت على خطتك لـ٦–١٢ شهر، أبقها P3 وامنحها وزناً. إذا لا تعنيك الذكاء الاصطناعي حالياً، اتركها P4 — وعد بعد ٦ أشهر.

كيف نقارن الأسعار حين يستخدم البائعون نماذج مختلفة؟#

معظم IdPs بالتسعير "المستخدمون النشطون شهريًا (MAU)". لكن تعريف MAU يختلف — بعضهم يعتبر أي دخول، آخرون مستخدم فريد، وبعضهم جلسات M2M منفصلة. اطلب من البائع عرض سعرك الخاص: عدد X مستخدم، Y مؤسسة، Z ربطات M2M، مع حجم دخولك المتوقع. قارن التكلفة الكلية لا سعر الوحدة.

خلاصة القول#

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

يغطي إطار التقييم أعلاه ما يهم فعليًا — لا مجرد نقاط التسويق. استعمله لتصفية المرشحين بسرعة (ابدأ بـP1)، وقيّم بعمق (معايير P2 وP3 مع اختبارات إثبات المفهوم)، واتخذ قرارًا يصمد لسنوات لا أشهر.

الفرق التي تتقن ذلك يجمع بينها شيء واحد: تعامِل الهوية كبنية تحتية، لا ميزة للاستعجال وشحنها.