OIDC أم SAML: أيهما تحتاج فعلاً

يصطدم كل فريق يبني برمجيات B2B بالمفترق نفسه أول مرة يقول فيها عميل جاد "نحتاج إلى SSO". اختصاران، OIDC وSAML، كلاهما يدّعي أنه الجواب، وإنترنت مليء بجداول المقارنة التي تخبرك أن SAML "للمؤسسات" وأن OIDC "حديث" وتتركك عالقاً تماماً كما كنت. إليك النسخة التي تساعدك فعلاً على إطلاق منتجك.

ما هما

SAML يعود إلى عام 2005 وهو XML. يوقّع موفّر الهوية تأكيداً ("هذه [email protected]، وهذه مجموعاتها") ويرسله إلى تطبيقك، الذي يتحقق من التوقيع ويسجّل دخولها. صُمّم للمتصفح ولهوية القوى العاملة، في عصر كانت فيه "المؤسسة" تعني Active Directory محلياً وحزمة SOAP. إنه مُسهب وقديم، وموجود في كل مكان داخل المؤسسات الكبيرة، وهذه هي الحقيقة الوحيدة عنه التي تهمّك.

OIDC يعود إلى عام 2014 وهو JSON وJWT، ويقع فوق OAuth 2.0. يُصدر موفّر الهوية رمز هوية (ID token) يتحقق منه تطبيقك. صُمّم للويب الحديث: تطبيقات الصفحة الواحدة، وتطبيقات الجوال، وواجهات برمجة التطبيقات، وتسجيل الدخول الاجتماعي. إنه أنظف، وأفضل توصيفاً للأشياء التي تبنيها فعلاً اليوم، وهو البروتوكول الذي تتحدث به معظم مشاريع الهوية الجديدة الآن.

متى يتفوّق كل منهما

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

• عميل يستخدم Okta أو Entra ID أو Google Workspace يستطيع عادةً استخدام أيٍّ منهما، وOIDC هو المسار الأجمل.
• عميل يستخدم ADFS قديماً، أو موفّر هوية محلياً عتيقاً، أو قائمة شراء كُتبت في 2016، سيسلّمك كتلة من بيانات SAML الوصفية ودعوة في التقويم، وهذه نهاية النقاش.
• تطبيقاتك الخاصة، لوحة التحكم وعميل الجوال لديك، تريد OIDC، نقطة انتهى. لن تلجأ أبداً إلى SAML لتسجيل دخول مستخدم إلى تطبيق React الخاص بك.

هكذا ينقسم الميدان بوضوح: OIDC للحديث وللتطبيقات الخاصة، وSAML "لأن المؤسسة قالت ذلك". بِع لعدد كافٍ من المؤسسات وسيُطلب منك كلاهما. ليس في النهاية. بل مراراً وتكراراً.

المزالق، وهنا يصبح بناؤه بنفسك مكلفاً

مشكلة SAML أنه بروتوكول قائم على XML موقّع، وXML الموقّع من أكثر الأشياء خطورةً على نحوٍ موثوق في التشفير التطبيقي. طرق ارتكاب الخطأ في التحقق من توقيع SAML كثيرة ومشهورة:

• التفاف التوقيع (XSW): يحرّك المهاجم العنصر الموقّع ويدسّ تأكيداً مزوّراً غير موقّع في الموضع الذي يقرأ منه محلّلك فعلاً. إذا تحققت من التوقيع وقرأت التأكيد في خطوتين منفصلتين، فأنت على الأرجح معرّض للخطر، وكل تطبيق أول تقريباً يفعل ذلك بالضبط.
• التوحيد القياسي وحقن التعليقات: فئة الثغرات لعام 2018 حيث يخضع [email protected]<!---->.evil.com للتوحيد القياسي بطريقة عند التحقق من التوقيع وبطريقة أخرى عند السلسلة النصية التي يقرأها كودك، فتصادق بمرح على الشخص الخطأ. ثغرات CVE حقيقية، في عدة مكتبات كبرى.
• الأقل ضجيجاً: توقيع الاستجابة دون توقيع التأكيد، قبول تأكيدات غير موقّعة، الوثوق بالمُصدِر الذي يوفّره موفّر الهوية دون تثبيته، الخطأ في نافذة صلاحية التأكيد. كلٌّ منها مزلق بحدّ ذاته، وكلٌّ منها أُطلق إلى الإنتاج على يد أناس يعرفون ما يفعلون.

OIDC أعقل بمعنى ملموس، لكنه ليس خالياً من الحواف الحادة. لا يزال عليك التحقق من المطالبات الصحيحة (iss وaud وexp وnonce)، واستخدام PKCE، ورفض التدفق الضمني الميّت منذ زمن، وتدوير JWKS وتخزينها مؤقتاً دون رفض رمز موقّع بمفتاح لم تجلبه بعد. الفرق أن مزالق OIDC موثّقة وعلى هيئة JSON، وتُعالَج بشكل صحيح افتراضياً في معظم المكتبات. أما مزالق SAML فعلى هيئة XML، وقد ابتلعت فرق أمان أوفر موارد بكثير من فريقك.

الجواب الحقيقي

"OIDC أم SAML" سؤال خاطئ، لأن الجواب الصحيح لمنتج B2B هو "نعم". عملاؤك المعاصرون وتطبيقاتك الخاصة يريدون OIDC. وعملاؤك من المؤسسات سيفرضون SAML وفق جدول زمني لا تتحكم به. ابنِ لأحدهما، وستكسره مكالمة المبيعات الثالثة.

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

وهذا هو الجزء الذي يتولّاه Authagonal نيابةً عنك. يحصل كل مستأجر على SAML 2.0 مع استيراد البيانات الوصفية بنقرة واحدة، واتحاد OIDC مع الموفّرين الذين يشغّلهم عملاؤك أصلاً، على شاشة تسجيل الدخول نفسها، دون رسوم لكل اتصال لأيٍّ منهما. أنت لا تنفّذ التحقق من توقيع XML، ولا تجالس ذاكرة JWKS المؤقتة، ولا تعيد بناء أيٍّ من ذلك حين يظهر العميل التالي متحدثاً بالبروتوكول الآخر. اطّلع على ما هو مُضمَّن.