16 نوفمبر 2025·7 دقيقة
OAuth مقابل SAML لـ SSO: ماذا يتوقع المشترون المؤسسيون
شرح مبسّط لـ OAuth مقابل SAML لـ SSO، وما تطلبه المؤسسات، ماذا تبني، وكيف تحافظ على طريقة تسجيل الدخول الحالية.
شرح مبسّط لـ OAuth مقابل SAML لـ SSO، وما تطلبه المؤسسات، ماذا تبني، وكيف تحافظ على طريقة تسجيل الدخول الحالية.
تصبح مسألة SSO عاجلة بمجرد انتقال الصفقة من "تجربة فريق" إلى طرح على مستوى الشركة. قد يعجب المشتري بمنتجك، لكن فرق الأمن وتقنية المعلومات ستبطئ الشراء إذا اضطر الموظفون لإنشاء كلمات مرور جديدة، إدارة MFA في مكان آخر، أو تُترك حسابات عند تغيّر الأدوار.
بالنسبة للعديد من المؤسسات، SSO أقل مسألة راحة وأكثر مسألة تحكم. يريدون مكانًا واحدًا لفرض قواعد تسجيل الدخول، سحب الوصول بسرعة، وإظهار للمراجعين أن الهوية تُدار مركزيًا. لهذا يظهر سؤال "OAuth vs SAML for SSO" متأخرًا في دورة المبيعات: إنه طريقة سريعة لمعرفة ما إذا كنت تناسب بنية هويتهم.
إضافة SSO في وقت متأخر قد يكسر افتراضات بنيت عليها بالفعل. إذا كان نموذجك الحالي "بريد واحد = مستخدم واحد"، فإن SSO يدخل حالات طرفية مثل الألقاب المشتركة، مزودي هوية متعددين، أو مستخدمين يحتاجون للاحتفاظ بتسجيل الدخول عبر كلمة مرور وSSO أثناء الهجرة. إذا كان ربط الحسابات خاطئًا، يفقد الأشخاص الوصول أو، الأسوأ، يحصلون على وصول إلى المستأجر الخطأ.
SSO يغيّر أيضًا طرق الانضمام والدعم. إذا أنفِق جيدًا، يقلل من إعادة تعيين كلمات المرور وتذاكر "من يملك هذا الحساب؟". إذا تم بشكل سيئ، تتعثر عمليات النشر، يغضب المشرفون، وتصبح التجديدات محفوفة بالمخاطر لأن المنتج "عمل في التجربة" لكنه يفشل في اليوم الأول من النشر المؤسسي.
القرار نادرًا ما يكون لشخص واحد. المشتري يريد زخمًا، فريق الأمن يختبر المخاطر والتدقيق، مدراء تقنية المعلومات يريدون خطوات إعداد واضحة، المستخدمون النهائيون يريدون تسجيل دخول سلس، والدعم يتعامل في النهاية مع حالات القفل والهجرة والاستثناءات.
إذا بنيت تطبيقات على منصات مثل Koder.ai، فمن المفيد التخطيط لـ SSO مبكرًا حتى لا تضطر لإعادة تصميم الهوية بعد أن يصبح العملاء نشطين.
SSO (تسجيل الدخول الأحادي) يعني أن عميلك يسجل الدخول إلى تطبيقك باستخدام تسجيل الدخول الخاص بالشركة، وليس كلمة مرور منفصلة تخزنها أنت. يتم الدخول بحساب العمل ويخضع الوصول لسياسة الشركة.
المصطلحات التي ستسمعها في مكالمات المؤسسات:
عندما يقول الناس "تسجيل الدخول OAuth"، كثيرًا ما يقصدون OpenID Connect (OIDC). OAuth مخصص أساسًا للتفويض (إعطاء إذن لنظام لاستدعاء API آخر). يضيف OIDC طبقة المصادقة (من هو المستخدم)، لذا يمكن استخدامه لتسجيل الدخول.
SAML معيار أقدم يعتمد على XML. لا تزال المؤسسات تستخدمه بكثافة لأنه مجرّب ومدعوم على نطاق واسع من قبل IdP ومذكور في قوائم امتثال عديدة.
SCIM ليست SSO. SCIM مخصّصة للتوفير: إنشاء المستخدمين وتحديثهم وتعطيلهم تلقائيًا (وأحيانًا المجموعات). الإعداد الشائع هو SAML أو OIDC لتسجيل الدخول، بالإضافة إلى SCIM حتى تتم إضافة وإزالة الوصول بدون عمل إداري يدوي.
فرق المؤسسات عادةً لا تبدأ بتفاصيل البروتوكول. يبدأون بالمخاطر والتحكم: "هل يمكننا إدارة الوصول من مزود هويتنا، وهل نستطيع إثبات من فعل ماذا؟"
تريد معظم فرق المؤسسات خيارًا واحدًا مناسبًا للمؤسسات على الأقل، وكثير منهم يريد كلا الخيارين:
كما سيسألون كيف تتم عملية الإعداد: بيانات وصفية أو URL اكتشاف، تدوير الشهادات، وهل يمكن لقسم تقنية المعلومات إعدادها ذاتيًا دون انتظار مهندسيك.
أسرع طريقة لفقدان صفقة مؤسسية هي أن تكون غامضًا بشأن إيقاف الوصول. سيُسألون ماذا يحدث عندما يغادر موظف، يغيّر قسمه، أو يفقد حاسوبه المحمول.
توقع أسئلة مثل:
سيناريو بسيط يهمهم: يقوم المشرف بتعطيل مستخدم في الساعة 9:02، وبحلول 9:03 لا يجب أن يستطيع ذلك المستخدم فتح التطبيق، حتى لو بقي لديه تبويب متصفح مفتوح. إذا لم تستطع شرح ذلك بوضوح، توقع دورات مراجعة إضافية.
بُني OAuth في الأصل للتفويض المفوض: السماح لنظام واحد باستدعاء API لنظام آخر دون مشاركة كلمة مرور. لا تزال الفرق تستخدمه لذلك (مثال: تكامل يقرأ التقاويم). لتسجيل دخول الموظف، يستخدم معظم المنتجات OpenID Connect (OIDC)، الذي يجلس فوق OAuth ويضيف طريقة معيارية لإثبات هوية المستخدم.
مع OIDC، الإعداد الشائع هو authorization code flow. يرسل تطبيقك المستخدم إلى IdP الشركة لتسجيل الدخول. بعد تسجيل ناجح، يعيد IdP إلى تطبيقك رمز تفويض قصير الأمد. يبدّل الخادم الخلفي ذلك الرمز بالتوكنات.
التقسيم الذي يهم:
طريقة عملية للتفكير في OAuth مقابل SAML لـ SSO: OIDC ممتاز عندما تريد تسجيل دخول حديث يناسب الويب، الجوال، وأنماط API. SAML أكثر شيوعًا عندما تريد المؤسسة مصافحة "تسجيل الدخول إلى التطبيق" الكلاسيكية ولا تهتم كثيرًا بوصول API.
ما تخزنه يجب أن يبقى بسيطًا: معرف المستخدم الثابت (subject)، بريده الإلكتروني (إن وُفّر)، واتصال التينانت الذي استخدمه. لا تخزن كلمة مرور المستخدم. أيضًا تجنّب تخزين توكنات تجديد طويلة الأمد إلا إذا كنت بحاجة فعلًا لوصول API دون اتصال.
لكي يعمل هذا على مستوى كل تينانت، ستحتاج إلى:
إذا نُفّذ بشكل صحيح، يعود المستخدم إلى تطبيقك، تتحقق من التوكنات، وتُنشئ جلستك العادية دون إعادة كتابة نموذج المصادقة كله.
تسمح SAML لـ IdP المؤسسي بأن يخبر تطبيقك: "هذا الشخص قد سجّل الدخول بالفعل، هذه تفاصيله." يرسل IdP تصريح SAML، وهو في الأساس ملاحظة موقّعة تتضمن من هو المستخدم (وأحيانًا معلومات المجموعات أو الأدوار) بالإضافة إلى نافذة صلاحية قصيرة.
لجعل تلك الملاحظة موثوقة، تعتمد SAML على بيانات وصفية وشهادات. البيانات الوصفية حزمة إعداد صغيرة تصف النقاط النهائية والمفاتيح. الشهادات تُستخدم بشكل رئيسي للتوقيع، حتى يتمكن تطبيقك من التأكد أن التصريح جاء من IdP العميل ولم يتم تغييره.
يظهر معرفان في تقريبًا كل إعداد:
إذا كان أي منهما خاطئًا، يفشل تسجيل الدخول حتى لو بدا كل شيء آخر صحيحًا.
SAML في العالم الواقعي عملية تشغيل بقدر ما هي برمجة. خطط لإعدادات SAML على مستوى التينانت، تدوير الشهادات بدون توقف، انحراف الساعة (clock skew) — فحتى بضع دقائق قد تكسر التصريحات — وأخطاء واضحة للمشرفين (ليس مجرد "استجابة غير صالحة").
نمط شائع: يقوم مشرف العميل بتمكين SAML لكل تينانت، ثم يتحقق تطبيقك من التوقيع، ويتأكد أن التصريح لم ينتهِ، ويطابق البريد الإلكتروني (أو NameID) مع مستخدم موجود أو قاعدة توفير آمنة. في الممارسة، هذا هو جوهر قرار OAuth مقابل SAML: SAML عادةً يجبرك على بناء سير عمل مشرف أقوى.
الاختيار بين OIDC وSAML يتعلق غالبًا بما يشغّل العميل بالفعل. تنتهي العديد من تطبيقات B2B بدعم كلاهما مع الوقت، لكن يمكنك اتخاذ قرار واضح لكل عميل والحفاظ على نظام مصادقة متوقع.
OIDC عادةً أكثر سلاسة للتطبيقات الحديثة. يناسب متصفحات الويب والتطبيقات المحمولة، ويتعامل جيدًا مع APIs، وغالبًا أسهل للتصحيح والتمديد (النطاقات، أعمار التوكن، إلخ). إذا كان عميل المؤسسة يستخدم إعداد IdP حديثًا وفريق تقنية المعلومات مرتاحًا مع OIDC، ابدأ به.
SAML يمكن أن يكون غير قابل للتفاوض. لدى العديد من الشركات الكبيرة برامج SAML وقواعد تسجيل البائعين مثل "SAML فقط." في هذه الحالات، الأفضل تنفيذ SAML مرة واحدة بطريقة مُتحكم بها وإبقاؤه معزولًا عن بقية نظام تسجيل الدخول.
أسئلة لطرحها قبل الالتزام:
دليل قرار سريع:
إذا دعمت كلا الطريقتين، حافظ على بقية التطبيق متسقة: نموذج مستخدم داخلي واحد، نموذج جلسة واحد، ومجموعة قواعد تفويض واحدة. يجب أن تجيب طريقة SSO عن "من هذا المستخدم ولأي تينانت ينتمي؟" وليس إعادة كتابة كيفية عمل الوصول.
ابدأ بتحديد معنى "تينانت" في منتجك. بالنسبة لمعظم تطبيقات B2B، يُعد SSO لكل مؤسسة أو مساحة عمل، وليس لكل مستخدم. هذا القرار يحدد أين تخزن إعدادات IdP، من يمكنه تغييرها، وكيف ينتقل المستخدمون بين مساحات العمل.
بعدها، اختر سلوك تسجيل دخول متوقع. توجيه بناءً على نطاق البريد (أدخل البريد، ثم أعد التوجيه إذا كان النطاق مفعلًا لـ SSO) يقلل الالتباس، لكن يجب التعامل مع حالات الحافة مثل المتعاقدين والشركات متعددة النطاقات. زر "المتابعة عبر SSO" بسيط وأسهل للفهم، لكن قد يختار المستخدم الخيار الخاطئ.
ترتيب بناء آمن لأي من OIDC أو SAML:
الاختبار ليس خيارًا. استخدم IdP رملية وتينانت مرحلة بنطاقات واقعية. اختبر السيناريو السليم وحالات الفشل: شهادة منتهية، جمهور خاطئ، انحراف الساعة، مستخدم مُزال من IdP. اعتبر طرح SSO كعلم ميزة.
منصات مثل Koder.ai تجعل هذا النوع من التكرار أسهل بدعمها للقطات والإرجاع مع إعداد per-tenant، حتى لا يقفل تغيير خاطئ كل عميل مرة واحدة.
SSO ليس مجرد زر تسجيل دخول. ستسأل فرق الأمان عن طول الجلسة، إيقاف الوصول، وماذا يمكنك إثبات عند حدوث مشكلة. إذا عاملت SSO كجزء أساسي من نظام المصادقة (وليس ملحقًا)، ستتجنب معظم التصعيدات المؤلمة.
ابدأ بقواعد الجلسة. اختر مهلة عدم نشاط ومدة جلسة مطلقة، وكن واضحًا بشأن ما يحدث عند إغلاق الحاسوب والعودة في اليوم التالي. مع OIDC، يمكن لتوكنات التجديد إبقاء الجلسات حية لفترة أطول من المتوقع، لذا ضع حدودًا (تدوير، أقصى عمر) إذا كنت تستخدمها. مع SAML، يمكن أن تبقى جلسات المتصفح طويلة ما لم تجبر على إعادة المصادقة.
تسجيل الخروج فخ آخر. "تسجيل الخروج الموحد" ليس معممًا. ادعم تسجيل الخروج المحلي بشكل موثوق ووثق أن تسجيل الخروج العالمي عبر كل التطبيقات يعتمد على IdP.
MFA مشابه. ترغب المؤسسات أن يفرض IdP المصادقة متعددة العوامل، لذا يجب أن يقبل تطبيقك مستخدمًا مُوثقًا دون مطالبة إضافية. مع ذلك، من المفيد دعم خطوات رفع مستوى المصادقة لإجراءات حساسة (مثل تصدير البيانات أو تغيير الفوترة)، لأن ليست كل سياسات IdP مثالية.
توفير المستخدمين هو المكان الذي تحدث فيه تسريبات الوصول. التوفير عند الطلب (JIT) مريح، لكنه قد ينشئ حسابات لأي شخص يمكنه المصادقة. الدعوة فقط أكثر أمانًا لكنها تضيف عملًا إداريًا. الكثير من الفرق يتفقون على حل وسط: يسمحون بـ JIT لكن يقيّدونه بنطاقات مسموح بها وادعاءات المجموعات.
احتفظ بإعدادات SSO خلف أدوار أقل امتيازًا. لا ينبغي أن يحتاج شخص لمنصب عالي فقط لتدوير شهادة أو تحديث URL IdP.
للدعم، سجّل ما يكفي لتتبع تسجيل دخول واحد دون تخزين أسرار:
هذا الفارق بين "لا نستطيع إعادة إنتاجه" وإصلاح انقطاع SSO لمؤسسة في دقائق.
تتواصل شركة متوسطة إلى قسم المشتريات وتقول: "نحتاج SSO قبل التوقيع." نادرًا ما يكون هذا نقاشًا فلسفيًا. إنه ضابط تحكم يحتاجونه للانضمام، والإلغاء، والتدقيق.
الالتواء: أنت تبيع لفرقتين. الفريق A راضٍ عن OIDC لأنهم يستخدمون Okta مع تطبيقات حديثة. الفريق B يصر على SAML لأن أدواتهم القديمة ما تزال تعتمد عليه. هنا يتوقف سؤال OAuth vs SAML عن كونه نقاشًا ويصبح خطة نشر.
احتفظ بقاعدة واحدة: SSO خيار تسجيل دخول per-tenant، ليس استبدالًا عالميًا. يمكن للمستخدمين الحاليين الاستمرار بتسجيل الدخول بالطريقة القديمة حتى يُفعّل مشرف التينانت "SSO مطلوب."
عند أول تسجيل دخول عبر SSO، تحتاج ربط حسابات آمن. نهج نظيف هو: مطابقة على البريد الإلكتروني الموثق، تأكيد التينانت عبر النطاق (أو دعوة)، ثم ربط هوية IdP بالحساب الموجود. إذا لم يوجد تطابق، أنشئ المستخدم عند الطلب فقط إذا سمح المشرف بذلك.
تعيين الأدوار هو المكان الذي تتعطل فيه الصفقات غالبًا. اجعلها بسيطة: دور افتراضي للمستخدمين الجدد، وخريطة اختيارية من مجموعات IdP أو ادعاءات إلى أدوارك.
على جانب المشرف، عادةً ما يحتاجون لتكوين:
لتجنب الإقفال أثناء التبديل، احتفظ بحساب مشرف للطوارئ خارج SSO، شغّل وضع اختبار لأول تسجيلات الدخول، ولا تُلزِم SSO إلا بعد جلسة مشرف عاملة ومؤكدة.
معظم حوادث SSO لا يسببها IdP. تحدث لأن تطبيقك يتعامل مع SSO كمفتاح عالمي، لا كإعداد لكل عميل.
فشل كلاسيكي هو فقدان حدود التينانت. يتم حفظ إعداد IdP واحدًا عالميًا، فجأة يُعاد توجيه كل عميل إلى آخر IdP عدّلته. اربط إعدادات IdP بالتينانت دائمًا، وحل التينانت قبل بدء مصافحة SSO.
مطابقة الحسابات فخ كبير آخر. إذا اعتمدت على البريد الإلكتروني وحده، ستنشئ مستخدمين مكرّرين أو تحرم مستخدمين حقيقيين من الوصول عندما يختلف بريد IdP عن البريد الذي استخدموه قبل SSO. عرّف سياسة الدمج مسبقًا: أي المعرفات تثق بها، كيفية التعامل مع تغييرات البريد، وكيف يمكن للمشرفين إصلاح الاختلافات بدون مساعدة هندسية.
تميل الفرق أيضًا إلى الثقة الزائدة بالادعاءات. تحقق مما تتلقاه: issuer، audience، التوقيع، وأن البريد موثق (أو استخدم معرف subject ثابت بدلًا منه). قبول جمهور خاطئ أو بريد غير موثق طريقة سهلة لمنح وصول للشخص الخطأ.
عند الفشل، الأخطاء الغامضة تطيل مكالمات الدعم. أعط المستخدم رسالة واضحة، ومشرفًا تلميح تشخيصي (مثلاً: "عدم تطابق الجمهور" أو "انتهت صلاحية الشهادة") دون كشف أسرار.
مسائل الوقت تستحق الاختبار قبل الإطلاق. انحراف الساعة وتدوير الشهادات يكسران تسجيلات الدخول صباح يوم الاثنين.
خمسة فحوصات تمنع معظم الانقطاعات:
SSO هو المكان الذي تتحول فيه افتراضات صغيرة إلى تذاكر دعم كبيرة. قبل أن تقول لعميل مؤسسي إنك تدعم SSO، تأكد أن الأساسيات موجودة في منتجك، ليس فقط في العرض التوضيحي.
نفّذ هذه الخطوات في بيئة مرحلة تحاكي الإنتاج:
قم بتدريب "يوم سيء" كامل: دوّر شهادة، غيّر ادعاء، أو اكسر URL IdP وتأكد أنك تستطيع اكتشافه بسرعة.
ثم أكد أن لديك مراقبة وتنبيهات لفشل SSO (مفصلة حسب التينانت)، وخطة تراجع (ميزة علمية، إعادة إعداد، أو نشر سريع) قد مارستها مسبقًا.
اختر نقطة بداية واضحة. معظم مشترِي المؤسسات يطلبون "SAML مع Okta/Entra ID" أو "OIDC مع Google/Microsoft"، ولا تريد أن تعد بدعم كلاهما في الأسبوع الأول إلا إذا كان لديك الفريق لذلك. قرر ما ستدعمه أولًا (SAML فقط، OIDC فقط، أو كلاهما) ودوّن تعريف "مكتمل" لمنتجك وفريق الدعم.
قبل إشراك عميل حقيقي، أنشئ تينانت داخلي تجريبي صغير. استخدمه لتدريب التدفق الكامل: تفعيل SSO، اختبار الدخول، تقييد النطاق، واستعادة الوصول عند حدوث مشكلة. هنا أيضًا تُختبر خطة الدعم.
حافظ على مستند متطلبات المؤسسات حيًا. المراجعات تتغير مع الوقت، ووجود مكان واحد لتتبع ما تدعمه يمنع الوعود الفردية التي تكسر لاحقًا عملية الانضمام.
خطة بسيطة تعمل في الممارسة:
إذا أردت التحرك سريعًا على مستوى المنتج، يمكنك نمذجة شاشات الإعداد وبنية التينانت في Koder.ai (koder.ai) والتكرار أثناء وصول استمارات أمن العملاء.
خطط للإضافات التي تتبع عادةً مباشرة بعد SSO: توفير SCIM، تصدير سجلات التدقيق، وأدوار مشرفين بصلاحيات واضحة. حتى إن لم تُطلقها فورًا، سيطلبها المشترون، ويجب أن يكون جوابك متسقًا.
تريد فرق المؤسسات تحكماً مركزياً في الوصول. يتيح لهم SSO فرض سياسات MFA وتسجيل الدخول من مزوّد الهوية الخاص بهم، وسحب الوصول بسرعة عند مغادرة الموظف، وتلبية متطلبات التدقيق دون الاعتماد على تطبيقك لإدارة كلمات المرور بشكل صحيح.
ابدأ بما يدعم مزوِّد الهوية لديهم وما تتطلبه سياسة قبول البائعين. غالباً ما يكون OIDC أسهل للتكامل مع تطبيقات الويب والهاتف الحديثة، بينما قد يكون SAML إلزامياً في شركات أكبر لأنه مذكور في برامج وإجراءات الدخول للسوق لديها.
OIDC هي طبقة مصادقة مبنية فوق OAuth ومصمّمة لتسجيل الدخول. OAuth وحده مخصّص أكثر لتخويل الوصول إلى واجهات برمجة التطبيقات، وليس لإثبات هوية المستخدم. عند قول "تسجيل الدخول عبر IdP للشركة" فإن المقصود تقريبًا هو OIDC وليس OAuth الخام.
لا. SSO يخص تسجيل الدخول، بينما SCIM مخصّص لتوفير المستخدمين: إنشاءهم، تحديثهم، وتعطيلهم تلقائياً (وأحيانًا المجموعات). الإعداد الشائع لدى المؤسسات هو SAML أو OIDC لتسجيل الدخول، وSCIM لإدارة الإلغاء والتغييرات بدون عمل يدوي في التطبيق.
عامل SSO كإعداد مرتبط بكل تينانت وليس كمفتاح عالمي. حدّد التينانت أولًا (عن طريق توجيه النطاق، دعوة، أو اختيار المؤسسة) ثم ابدأ مصافحة SSO باستخدام إعدادات IdP الخاصة بذلك التينانت. هذا يمنع إعدادات IdP الخاصة بعميل واحد من التأثير على عملاء آخرين.
استخدم معرفًا ثابتًا من IdP (مثل sub في OIDC أو NameID في SAML) كرابط أساسي، واجعل البريد الإلكتروني سمة ثانوية قابلة للتغيير. عند أول تسجيل دخول عبر SSO اربط الحساب الموجود فقط عندما تكون واثقًا أنه نفس الشخص والتينانت صحيح؛ وإلا اطلب دعوة أو تأكيد من المشرف.
احتفظ بحساب مشرف للطوارئ يمكنه تسجيل الدخول بدون SSO، واجعل SSO اختيارياً حتى يؤكد مشرف أنه يعمل. أضف زرًا واحدًا لتعطيل SSO لذلك التينانت يمكن لفريق الدعم استخدامه لاستعادة الوصول بسرعة دون تعديل الشيفرة.
ادعم تسجيل الخروج المحلي داخل تطبيقك ووضّح أن تسجيل الخروج الشامل عبر كل التطبيقات يعتمد على ميزات IdP لدى العميل. ضع خطة لإبطال الوصول بسرعة عن طريق إنهاء الجلسات أو طلب إعادة المصادقة حتى لا يستطيع مستخدم معطل مواصلة الوصول من تبويب متصفح قديم.
سجّل ما يكفي لتتبع محاولة تسجيل دخول دون كشف أسرار. التقط معرّف تتبّع (correlation ID)، التينانت، معرف المُصدر/entity ID، الطوابع الزمنية، وسبب واضح للخطأ مثل فشل التوقيع، عدم تطابق الجمهور، أو انتهاء الشهادة. تجنّب تخزين التوكنات الخام، أو بيانات SAML الكاملة، أو الأسرار في السجلات.
تحتاج تخزين إعدادات على مستوى التينانت، واجهة إدارة لإعداد IdP، قواعد ربط حسابات آمنة، ومسار إرجاع. عند البناء على Koder.ai خطط لنموذج التينانت مبكراً واستخدم لقطات وإرجاع أثناء النشر حتى لا تمنع تغييرات خاطئة وصول جميع العملاء.