OpenID Connect و Oauth 2.0

جمادى الأولى 11 1443 - Ali - عام

مشاركة :

blog-banner

فهم حالة الاستخدام

 

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

إن فهم المشكلات التي تم تصميم أدواتنا لحلها هو الخطوة الأولى في جعل تطبيقاتنا أكثر أمانًا. يحدد إطار عمل OAuth 2.0 أنماط التفويض الشاملة ولكنه لا يحدد كيفية إجراء المصادقة.

يستخدم التطبيق OAuth لإرسال طلب أذونات محدد إلى نظام تابع لجهة خارجية ، يُعرف باسم موفر الهوية (IdP) ، والذي يتعامل مع المصادقة ويقدم رمز وصول يشير إلى النجاح.

قد يطلب موفِّر الهوية عوامل إضافية ، مثل الرسائل القصيرة SMS أو البريد الإلكتروني ، على الرغم من أن هذا خارج نطاق OAuth. أخيرًا ، بشكل افتراضي ، تظل محتويات وبنية رمز الوصول هذا غير معروفين. يضمن عدم اليقين هذا قيام موفري الهوية بإنشاء أنظمة غير متوافقة.

لحسن الحظ ، يوفر OpenID Connect أو OIDC بعض الترتيب للفوضى. إنه امتداد OAuth يقدم ويحدد بدقة رمز ID لإرجاع بيانات المستخدم. عندما نستخدم موفر الهوية الخاص بنا لتسجيل الدخول ، فقد يقوم الآن بإرجاع الحقول المحددة التي يمكن لتطبيقاتنا إدارتها. أهم شيء يجب أخذه في الاعتبار هو أن OIDC هو في الحقيقة نسخة مبسطة من OAuth ، وليس بديلاً. إنها تستخدم نفس اللغة والمبادئ.

OpenID Connect مقابل Oauth 2.0: تمييز المفاتيح

المعايير واختلافاتها

الفرق الرئيسي بين الاثنين هو أن OAuth 2.0 هو إطار عمل للتحكم في التفويض لمورد محمي ، مثل تطبيق أو مجموعة من الملفات ، في حين أن OpenID Connect و SAML كلاهما معايير صناعة مصادقة موحدة. يشير ذلك إلى أن OAuth 2.0 يتم استخدامه في سياقات مختلفة تمامًا عن البروتوكولين الآخرين (الأمثلة أدناه) ، ويمكن استخدامه مع OpenID Connect أو SAML في نفس الوقت.
 ● يمكن للشركات تحقيق مصادقة المستخدم وتثبيت تسجيل الدخول الأحادي باستخدام إما OpenID Connect أو SAML بمفردها. على الرغم من حقيقة أنهما يتعاملان مع عمليات تسجيل الدخول ، إلا أن لهما مزايا وعيوب واضحة.

● يعتمد OpenID Connect على بروتوكول OAuth 2.0 ويستخدم رمز ويب JSON إضافيًا (JWT) يُعرف باسم رمز ID لتوحيد المناطق التي يسمح فيها OAuth 2.0 بالمرونة ، مثل النطاقات واكتشاف نقطة النهاية. يركز على مصادقة المستخدم ويستخدم بشكل شائع على مواقع الويب الاستهلاكية وتطبيقات الأجهزة المحمولة لتسهيل عمليات تسجيل دخول المستخدم.

● على عكس JWT ، لا تعتمد SAML على OAuth وتعتمد بدلاً من ذلك على تبادل الرسائل للمصادقة بتنسيق XML SAML. يتم استخدامه عادةً للسماح لمستخدمي المؤسسات بتسجيل الدخول إلى تطبيقات مختلفة بكلمة مرور واحدة.

التحكم في الوصول والنطاقات

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

يتم وصف النطاقات على أنها OpenID ، وملف التعريف ، والبريد الإلكتروني ، والعنوان ، والهاتف في تعريف OpenID Connect وكل منها يتيح الوصول إلى تلك المعلومات المحددة. إذا كنت تستخدم نطاقًا غير ذلك ، فقد تركت تعريف OIDC وتتعامل الآن مع OAuth العام ، حيث تصبح الأمور صعبة.

بالنسبة إلى نطاقات معينة ، لا تحدد OAuth معايير التسمية أو العلاقات أو الوصول. من الناحية العملية ، هذا يعني أن نطاق الإدارة يمكن أن يعني أشياء مختلفة لأنظمة مختلفة ، بافتراض أنه يعني أي شيء. على الجانب الإيجابي ، فهذا يعني أن الشركات مثل Google يمكنها إنشاء نطاقات OAuth شديدة التنظيم ويمكن التنبؤ بها.

على الجانب السلبي ، لدى Github الآن نطاقات تسمى المستخدم ، والقراءة: المستخدم ، والمستخدم: البريد الإلكتروني الذي يوفر وصولاً للقراءة فقط إلى ملفات تعريف المستخدمين. في Android ، حدثت المشكلة نفسها عندما منحت تطبيق Facebook إمكانية الوصول إلى قائمة جهات الاتصال الخاصة بك ، والتي تتضمن رسائل SMS وسجل المكالمات. بالنسبة إلى نطاقات معينة ، لا تحدد OAuth معايير التسمية أو العلاقات أو الوصول.

من الناحية العملية ، هذا يعني أن نطاق الإدارة يمكن أن يعني أشياء مختلفة لأنظمة مختلفة ، بافتراض أنه يعني أي شيء. على الجانب الإيجابي ، فهذا يعني أن الشركات مثل Google يمكنها إنشاء نطاقات OAuth شديدة التنظيم ويمكن التنبؤ بها. على الجانب السلبي ، لدى Github الآن نطاقات تسمى المستخدم ، والقراءة: المستخدم ، والمستخدم: البريد الإلكتروني الذي يوفر وصولاً للقراءة فقط إلى ملفات تعريف المستخدمين.

في Android ، حدثت المشكلة نفسها عندما منحت تطبيق Facebook إمكانية الوصول إلى قائمة جهات الاتصال الخاصة بك ، والتي تتضمن رسائل SMS وسجل المكالمات.

إدارة المطالبات

بعد ذلك ، يجب علينا النظر في المطالبات بعناية. تحتوي رموز الوصول والمعرف الخاصة بنا على زوج اسم / قيمة يشار إليه باسم مطالبة. قد يكون لديك معرف مستخدم أو مطالبة بالبريد الإلكتروني ، على سبيل المثال ، بحيث يمكن للتطبيقات النهائية إنشاء ملفات تعريف أو إصدار أحكام بناءً عليها. الجانب المربك هو أن معيار OAuth Core لا يتضمن حتى المطالبات.

هذا مفيد لأنه يمكننا تعريفه على النحو الذي نراه مناسبًا. لسوء الحظ ، سيحددها الناس بالطريقة التي يرونها مناسبة. يقدم معيار JWT (RFC 7519) الفكرة ويحدد الهيكل الأساسي ، ومع ذلك ، فإنه لا ينشئ أي تسمية أو هيكل أو معايير أخرى. يمنحنا استخدام OpenID Connect المزيد من الأمان.

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

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

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

هذا مشابه للطريقة التي يتصارع بها Facebook مع عواقب إصدار الكثير من المعلومات حول شبكة المستخدم عبر واجهة برمجة التطبيقات الخاصة بهم.

متى ولأي سبب يجب عليك التقدم للحصول على منحة؟

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

كود التفويض

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

الجزء الحاسم مقسم إلى جزأين: بادئ ذي بدء ، بحلول الوقت الذي يرى فيه المستخدم رمز التفويض ، يكون قد تم استخدامه بالفعل ولا يمكن استخدامه مرة أخرى. ثانيًا ، يقوم البرنامج بتخزين Access Token في الخلفية. بافتراض أن البرنامج قد تم إنشاؤه بأمان ، سيتعين على المستخدم الضار ابتكار طريقة جديدة للهجوم.

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

ضمني

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

نظرًا لأنه من المحتمل أن يتفاعل المستخدم مع الرمز (الرموز) المميزة ، فمن الأهمية بمكان أن تعكس حالات الاستخدام لدينا ذلك. قد يكون السماح بإرسال الحوالات المصرفية إلى نطاق روسيا في تطبيق مصرفي فكرة سيئة ما لم يكن لدينا عوامل مصادقة إضافية للتأكد من أن الشخص المناسب يستخدمها. سيكون ذلك مفيدًا في المرة القادمة التي تخطئ فيها في وضع هاتفك.

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

كلمة المرور لمالك المورد

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

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

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

اعتماد العميل

نوع منح بيانات اعتماد العميل مخصص فقط للأنشطة من خادم إلى خادم في الواجهة الخلفية. فكر في الأمر على أنه حساب وكلمة مرور للخادم. من حيث المفهوم ، إنه مشابه لكيفية اتصال تطبيقك بأنظمة الخلفية الأخرى مثل قاعدة البيانات الخاصة بك أو Twilio.

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

الحد الأدنى

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

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

إشترك الآن

أدخل عنوان بريدك الإلكتروني لتصلك نشرتنا الإخبارية .

البريد الإلكتروني

الرؤى

عرض بعض أعمالنا الحديثة