إطار تقييم IdP عملي مبني على متطلبات الشركات الحقيقية. يغطي عمق البروتوكول، والهجرة، وتعدد المستأجرين، والاستعداد للذكاء الاصطناعي، والمعايير التي تتجاهلها معظم قوائم الفحص.
معظم المقالات التي تقارن مزودي الهوية مكتوبة من قبل مزودي الهوية أنفسهم. صادم، أليس كذلك؟ يذكرون الميزات التي تقدمها منتجاتهم، ويتجاهلون الميزات التي لا توفرها، ويسمونها "دليل موضوعي".
هذا الدليل مختلف.
لقد قمنا بمراجعة عشرات الطلبات الفعلية لتقييم المؤسسات — الجداول والوثائق الحقيقية (RFP) التي ترسلها فرق الشراء للبائعين. النمط واضح: فرق الهندسة تضع وزناً أقل للمعايير الأهم ووزناً أعلى للمعايير الأقل أهمية.
النتيجة؟ تختار الفرق مقدّم هوية IdP بناءً على عرض توضيحي، ويكتشفون بعد ستة أشهر أن قصة الهجرة كابوس، ويبدأون التقييم من جديد.
إليك إطار التقييم الذي تمنينا لو أعطانا أحد إياه عندما بدأنا. تم تصميمه لفرق الهندسة في شركات B2B SaaS — التي تبني المنتجات، وليس تلك التي تشتري SSO لموظفيها.
إذا كنت تتصفح بسرعة، فإليك النسخة المختصرة:
بقية هذا الدليل تستعرض كل بُعد من أبعاد التقييم بالتفصيل، مع أسئلة محددة يجب طرحها وإشارات تحذير يجب الانتباه لها.
هذا الدليل لك إذا:
هذا الدليل ليس لك إذا:
كل IdP في السوق سيخبرك أنه يدعم OAuth2 وOIDC. هذا أدنى مستوى مقبول. الأسئلة الحقيقية تتعلق بالعمق.
أساسي:
أصبحت حرجة بشكل متزايد:
هناك سؤال لا تفكر فيه معظم الفرق: هل يمكنك استخدام هذا IdP كمزوّد OIDC — وليس فقط كمستهلك OIDC؟
لماذا الأهمية: مع نمو SaaS الخاص بك، قد يرغب الشركاء والعملاء في استخدام نظام هويتك للدخول إلى أدواتهم الخاصة. تحتاج لإصدار الرموز وإدارة الموافقات وتعامل مع تسجيل تطبيقات الطرف الثالث. إذا كان IdP يسمح لك فقط باستقبال مزودي هوية خارجية ولا يمكنه أن يكون مزودًا، ستواجه طريقًا مسدودًا عند الحاجة للفدرالية الخارجية.
اسأل:
الرمز هو العقد بين IdP وخدماتك. إذا لم تستطع تخصيصه، يجب على كل خدمة لاحقاً استدعاء واجهات برمجة التطبيقات الإضافية لمعرفة ما يمكن للمستخدم فعله.
اسأل:
رمز يحمل { "org_id": "org_123", "role": "admin", "auth_level": 2 } يعني أن الوسيط البرمجي لواجهتك يستطيع اتخاذ قرار التفويض بسطر واحد. رمز يحمل فقط { "sub": "user_456" } يعني أن كل خدمة تحتاج للاتصال بـ IdP أو قاعدة بيانات للحصول على البقية. على نطاق واسع، الفرق بين هذا وذاك هو ٢ ميللي ثانية مقابل ٢٠٠ ميللي ثانية لكل طلب.
كل IdP يدعم البريد الإلكتروني/كلمة المرور وتسجيل الدخول الاجتماعي. تهانينا، لقد قلصت الخيارات إلى... جميعهم.
الاختلاف في التفاصيل التي لا تغطيها معظم العروض التوضيحية.
هنا تنفصل التقييمات عن العروض التوضيحية. إدارة الجلسات والرموز مملة حتى تنهار — وعندما تنهار يخرج كل مستخدميك دفعة واحدة.
ليست براقة. لكنها بالغة الأهمية.
app.yourproduct.com وواجهة API على api.yourproduct.com، هل يمكن للجلسات أن تشمل كلا النطاقين؟ كيف؟يريد المستخدمون البقاء مسجلين لأسابيع، لا دقائق. لكن جلسة دائمة لـ180 يوم تختلف أمنياً كثيرًا عن جلسة ٣٠ دقيقة.
اسأل:
التحكم المعتمد على الدور (RBAC) هو الأساسي. إذا لم يدعم IdP ذلك، لا يستحق التقييم. لكن في B2B SaaS، RBAC وحده لا يكفي.
مستخدموك ينتمون إلى مؤسسات. صلاحياتهم داخل كل مؤسسة تختلف عن صلاحياتهم على مستوى المنصة.
قد يكون المستخدم مشرفًا في المنظمة A ومشاهدًا في المنظمة B. نفس المستخدم، سياقين من الدور. إذا لم يكن IdP يمكنه نمذجة ذلك أصيلاً، ستبني نظام صلاحيات موازٍ داخل تطبيقك — وحينها لديك مصدران للحقيقة.
أسئلة:
للتطبيقات المالية، الصحية، أو أي منتج فيه عمليات عالية المخاطر: ليست كل الجلسات المصادق عليها متساوية.
مشاهدة لوحة تحكم؟ كوكي الجلسة يكفي. إجراء تحويل أموال؟ تحتاج تحقق MFA جديد—even لو كان المستخدم مسجلًا الدخول.
هذه هي المصادقة المتدرجة (step-up) وتحتاج مفهوم مستوى المصادقة (auth_level) كجزء أصيل في نظام الرموز.
اسأل:
auth_level يمكن للباك إند فحصها؟auth_level صلاحية انتهاء خاصة، مستقلة عن الجلسة؟إذا لم يدعم IdP ذلك أصيلاً، ستضطر لبنائه بنفسك — وهذا بالضبط نوع منطق الهوية الذي تشتري IdP لتتجنبه.
الوضع المثالي: وسيط API يقرأ الرمز، يرى المؤسسة والدور ومستوى المصادقة، ويتخذ قرار التفويض مباشرة بلا استدعاء خارجي.
الواقع مع الكثير من مزودي IdP: يخبرك الرمز فقط من هو المستخدم، وتحتاج مكالمة API إضافية لمعرفة الصلاحيات.
تلك المكالمة تضيف زمن تأخير، وتخلق اعتمادًا، وتدخل حالة فشل. مع 1000 طلب بالثانية لا تريد أن تحقق التفويض عن طريق الشبكة.
ثمة إحصائية لا يحب أحد ذكرها: معظم تقييمات IdP تنتهي ليس لأن IdP الجديد غير كاف، بل لأن الفريق لا يعرف كيف يهاجر مستخدميه الحاليين.
لو لديك 100,000+ مستخدم، الهجرة ليست "ميزة لطيفة" — بل هي المشروع كله.
1. الاستيراد بالجملة مع كلمات المرور المشفرة الحالية
لدى المستخدمين كلمات مرور مشفرة بـ bcrypt أو argon2 أو أي خوارزمية لديك. هل يمكن لـ IdP استقبال تلك الشفرات والتحقق منها مباشرة؟
إذا نعم: يدخل المستخدمون بكلماتهم الحالية ولا يشعرون بفارق. أفضل سيناريو.
إذا لا: يحصل الجميع على بريد "أعد تعيين كلمة المرور". ستخسر 30–50٪ من قاعدة المستخدمين أثناء الهجرة. ليست افتراضية — بل واقعية.
2. الهجرة التدريجية (الكسولة)
بدلًا من ترحيل الجميع دفعة واحدة، ترحلهم واحدًا واحدًا عند تسجيل دخولهم. أول دخول يضرب نظامك القديم، يحقق كلمة المرور، ثم ينشئ المستخدم في IdP الجديد. كل دخول لاحق عبر IdP مباشرة.
هذه الطريقة الأكثر أمانًا للقواعد الكبيرة، لكن تحتاج أن يدعم IdP:
3. الكتابة المتوازية (أنظمة متزامنة)
أثناء الانتقال، النظامان القديم والجديد نشطان. الكتابة تذهب للاثنين والقراءات تتحول تدريجيًا للجديد. توفر مسار تراجع لكنها معقدة تشغيليًا.
إذا لم يجب البائع بثقة، لم يفعل ذلك من قبل. واصل البحث.
B2B SaaS يعني تعدد المستأجرين. عملاؤك مؤسسات ذات عدة مستخدمين، أدوار وسياسات وصول. يجب على IdP أن يفهم ذلك أصيلاً.
بعض IdP لا توفر نموذج مؤسسة أصيل. يقترحون استخدام metadata (user.app_metadata.org_id = "123") كحل.
ينهار هذا سريعاً:
إذا قال البائع "يمكنك نمذجة المؤسسات عبر metadata"، فهذا مثل تخزين البيانات العلائقية في JSON. يعمل... حتى يفشل.
منذ 12 شهرًا، لم يكن هناك في قوائم التقييم شيء اسمه "مصادقة وكلاء الذكاء الاصطناعي". اليوم، إذا كنت تبني ميزات AI في منتجك — مساعدين، وكلاء مستقلين، سير العمل بالذكاء الاصطناعي — يحتاج IdP لمعالجة هوية من نوع جديد: العميل.
المصادقة التقليدية فيها طرفين: المستخدم والتطبيق. OAuth2 صمم لهذا.
وكلاء الذكاء الاصطناعي (العملاء) يدخلون طرفًا ثالثًا: كيان غير بشري يعمل نيابة عن المستخدم، ذات صلاحيات مقيدة وسجل تدقيق خاص.
Token Exchange (RFC 8693): يقدم العميل أوراقه بجانب تفويض المستخدم ويستقبل رمز بصلاحيات محددة. يحمل من (المستخدم)، ماذا (العميل)، مدى الصلاحية، ووقت الانتهاء.
عميل كنموذج OAuth2: يجب أن يكون العميل OAuth2 client بمعرفه الخاص، لا مجرد مفتاح API أو رمز مستخدم مشترك.
إدارة صلاحيات مندوَبة: يمكن للمستخدم منح صلاحيات معينة للعميل — قراءة بدون كتابة، موارد محددة دون الأخرى.
تمييز في السجلات: يجب أن تفرق سجلاتك بين "المستخدم قام بـX" و"العميل قام بـX نيابة عن المستخدم". إذا لم تميز ذلك، ستفشل تدقيق SOC2 القادم حين يسأل المدقق "من نفذ هذا التغيير؟"
MCP بات معيارًا لوكلاء الذكاء الاصطناعي للتفاعل مع الأدوات والخدمات. إذا كان IdP يدعم المصادقة عبر OAuth لـ MCP، يستطيع العملاء المصادقة بالشكل الصحيح عبر طبقة البروتوكول بدل مفاتيح أو أسرار مشتركة.
إذا لم يفكر البائع بهذا، يبني لعام 2020. وأنت تخطط لعام 2026.
الميزات تبيع. العمليات تحدد ما إذا كنت ستجدد.
بعد التقييم في كل بُعد، تحتاج طريقة للمقارنة. إليك إطار الأولوية:
| المعيار | لماذا هو P1 |
|---|---|
| استيراد شيفرة كلمات المرور أو الهجرة التدريجية | لا يمكن استخدامه بدون ترحيل |
| دعم Authorization Code + PKCE | أساس الأمان |
| نموذج مؤسسة أصيل | متطلب B2B SaaS |
| SOC2 نوع II أو خطة واضحة له | عملاء المؤسسات سيطلبونها |
| SLA تشغيل 99.9%+ | توقف المصادقة = توقف المنتج |
| المعيار | لماذا هو P2 |
|---|---|
| مطالبات JWT مخصصة | تجنب تحقق الصلاحيات لكل طلب |
| سياسات مصادقة لكل منظمة | توظيف عملاء الشركات |
| أدوار ورموز ضمن المنظمة | تفويض متعدد المستأجرين |
| تدوير وإلغاء رموز التحديث | أفضل ممارسات الأمان |
| واجهة مستضافة + خيار واجهة خاصة | مرونة لسيناريوهات مختلفة |
| المعيار | لماذا هو P3 |
|---|---|
| Token Exchange (RFC 8693) | مصادقة وكلاء الذكاء الاصطناعي |
| قدرة مزود OIDC | فدرالية الشركاء |
| مصادقة متدرجة / auth_level | عمليات مالية أو عالية المخاطر |
| توفير SCIM | مزامنة دلائل عملاء المؤسسات |
| دعم Passkey / WebAuthn | اتجاه بلا كلمة مرور |
| المعيار | لماذا هو P4 |
|---|---|
| لوحة تحكم التحليلات المدمجة | يمكن بناؤها من سجلات التدقيق |
| قوالب بريد مسماة | ميزة راحة |
| أداة بناء التدفق المرئي | ميزة راحة |
| موصلات تواصل اجتماعي جاهزة (ما بعد الخمس الكبار) | مزودون ثانويون |
كيفية استخدام هذا: ابدأ بـP1. إذا فشل البائع بأي معيار P1 توقف التقييم. ثم قيّم معايير P2 وP3. البائع الذي يحصل على أعلى مجموع في P2+P3 هو اختيارك.
رأينا الفرق تكرر نفس الأخطاء. إليك كيف تتجنبها:
جدول ميزات يخبِرك ما الموجود، لكنه لا يخبِرك كيف بني. ربما يدعم IdP المؤسسات بوضع معرف المؤسسة في metadata. يبدو ضمن القائمة لكنه يخلق مشاكل حقيقية إنتاجيًا.
الحل: لكل ميزة، اسأل "كيف بنيت؟" وليس فقط "هل لديك هذا؟"
تختار الفرق IdP "الأفضل"، تبدأ التنفيذ، ثم تكتشف عدم القدرة على ترحيل المستخدمين دون حملة إعادة تعيين كلمات المرور. الآن أمام خيارين: تجربة هجرة سيئة أو البدء من جديد.
الحل: اجعل قدرة الهجرة مرشحك الأول لا الأخير.
كل عروض البائعين مصقولة. تظهر السيناريو المثالي مع قاعدة بيانات نظيفة دون حالات حواف. بيئتك الفعلية فيها مستخدمون بدمج حسابات، يونيكود غريب، وجلسات متراكمة.
الحل: اطلب نموذج إثبات مفهوم ببياناتك الفعلية. استورد ١٠٠٠ مستخدم فعلي، ونفّذ تدفقات المصادقة الحقيقية.
إذا قيّم فريق المنصة وحده اختار الأنظف تقنياً. إذا قيّم المنتج فقط اختار الأسهل دمجاً. إذا قيّم الأمن فقط اختار الأكثر امتثالاً.
الحل: فريق التقييم يجب أن يشمل هندسة المنصة، المنتج، والأمان. كل منهم مسؤول عن معايير P1/P2 مختلفة.
الإغلاق مع البائع حقيقي. SDKs خاصة، APIs مخصصة، رموز غير قياسية — جميعها تجعل الهجرة لاحقاً أصعب.
الحل: فضل IdP الذي يستخدم بروتوكولات قياسية (OIDC, OAuth2, SCIM). مستقبلك سيشكرك.
لتقييم شامل مع اختبار إثبات المفهوم، جهز من ٤–٨ أسابيع. الاستعجال يؤدي للأخطاء أعلاه — خاصة تجاهل الهجرة. خصص أسبوعين لجمع المتطلبات، ٢–٣ أسابيع لتقييم البائعين وإثبات المفهوم، و١–٢ أسبوع لاتفاق المعنيين.
يعتمد على المرحلة. إذا كان لديك أقل من ١٠ آلاف مستخدم، ولا عملاء شركات، مكتبة مصادقة بسيطة قد تفي بالغرض. لكن فور الحاجة لـSSO، تعدد مستأجرين، MFA، وتوثيقات الامتثال فتكلفة الصيانة تفوق IdP جاهز. رأينا فرق هندسة كاملة تصرف راتب ٢–٣ موظفين بدوام كامل للصيانة — أي ٣٠٠-٥٠٠ ألف دولار سنويًا.
CIAM (إدارة هوية العملاء) يتفاعل معه المستخدمون النهائيون لمنتجك — تسجيل، دخول، إدارة بروفايل. workforce IAM لموظفيك لدخول الأدوات الداخلية (Okta لـ Slack الشركة، Google Workspace ...إلخ). قرارا شراء وتقييم منفصلان. هذا الدليل حول CIAM.
المفتوح يعطي شفافية (مراجعة الشيفرة)، قابلية النقل (تستضيف ذاتياً إن شئت)، مساهمات المجتمع. IdP الخاص قد يقدم واجهات مصقولة وخدمات مدارة. السؤال الأهم ليس "مفتوح أم مغلق" — بل "هل أستطيع المغادرة؟" الحلول مفتوحة المصدر تسهل المغادرة لأن النموذج وAPIs علنية.
إذا كنت تبني بالفعل ميزات ذكاء اصطناعي تصل لبيانات المستخدم، اجعلها P1 الآن. إذا كانت على خطتك لـ٦–١٢ شهر، أبقها P3 وامنحها وزناً. إذا لا تعنيك الذكاء الاصطناعي حالياً، اتركها P4 — وعد بعد ٦ أشهر.
معظم IdPs بالتسعير "المستخدمون النشطون شهريًا (MAU)". لكن تعريف MAU يختلف — بعضهم يعتبر أي دخول، آخرون مستخدم فريد، وبعضهم جلسات M2M منفصلة. اطلب من البائع عرض سعرك الخاص: عدد X مستخدم، Y مؤسسة، Z ربطات M2M، مع حجم دخولك المتوقع. قارن التكلفة الكلية لا سعر الوحدة.
اختيار مقدم الهوية قرار بنية تحتية، لا قرار ميزة جديدة. أنت تلتزم بنظام سيتعامل مع أول تفاعل لكل مستخدم مع منتجك، كل تحقق صلاحية في API، وكل سجل تدقيق يراجعه فريق الامتثال.
يغطي إطار التقييم أعلاه ما يهم فعليًا — لا مجرد نقاط التسويق. استعمله لتصفية المرشحين بسرعة (ابدأ بـP1)، وقيّم بعمق (معايير P2 وP3 مع اختبارات إثبات المفهوم)، واتخذ قرارًا يصمد لسنوات لا أشهر.
الفرق التي تتقن ذلك يجمع بينها شيء واحد: تعامِل الهوية كبنية تحتية، لا ميزة للاستعجال وشحنها.