oauth 2.0

OAuth 2.1

يعد OAuth 2.1 تحديثًا مقترحًا لإطار تفويض OAuth 2.0 يهدف إلى تحسين الأمان وسهولة الاستخدام من خلال إهمال التدفقات غير الآمنة وتقديم أفضل الممارسات الجديدة.

ما هو OAuth 2.1؟

OAuth 2.1 هو تحديث مقترح لإطار تفويض OAuth 2.0 . يتضمن سلسلة من التغييرات والتوصيات على مواصفات OAuth 2.0 الحالية التي توحد أفضل الممارسات وتحسينات الأمان التي تم اعتمادها على نطاق واسع في الصناعة على مر السنوات.

التحديثات الرئيسية لـOAuth 2.1 هي:

إهمال التفويض الضمني و إذونات كلمة مرور مالك المورد (ROPC) بسبب المخاوف الأمنية.
فرض استخدام مفتاح إثبات تبادل الكود (Proof Key for Code Exchange, PKCE) لجميع العملاء، بما في ذلك العملاء السرية (الخاصة) .
المطابقة الدقيقة لـ عناوين URI الخاصة بإعادة التوجيه .
تعريف واضح لأنواع العملاء (عملاء عامين وسريين).
متطلبات الأمان ل رموز التحديث .

إهمال التفويض الضمني

تم تصميم التفويض الضمني للتطبيقات ذات الصفحة الواحدة (SPAs) والتطبيقات المعتمدة على المتصفح التي لا يمكنها تخزين أسرار العملاء بأمان. ومع ذلك، فإن مخاطر الأمان الخاصة به أدت إلى إهماله: يعود التفويض بtoken الوصول في القناة الأمامية (جزء URL) الذي يمكن كشفه للمهاجمين عبر تاريخ المتصفح وراسلس للتوجيه.

يوصي OAuth 2.1 باستخدام تفويض رمز الإذن مع مفتاح إثبات تبادل الكود (Proof Key for Code Exchange, PKCE) للتطبيقات المعتمدة على المتصفح.

إهمال إذونات ROPC

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

كشف بيانات اعتماد المستخدم للعميل.
تجاوز شاشة الموافقة لخادم التفويض.
تحديد قدرة خادم التفويض على تنفيذ إجراءات أمان أخرى، مثل المصادقة متعددة العوامل (Multi-factor authentication, MFA) .

يوصي OAuth 2.1 باستخدام تفويض رمز الإذن مع مفتاح إثبات تبادل الكود (Proof Key for Code Exchange, PKCE) للمصادقة وتفويض المستخدم.

فرض PKCE لجميع العملاء

مفتاح إثبات تبادل الكود (Proof Key for Code Exchange, PKCE) هو امتداد أمني لتدفق رمز الإذن الذي يحد من خطر اعتراض رمز الإذن. يتضمن قيام العميل بتوليد رمز تحقق وتحدي، والتأكد من التحدي بواسطة خادم التفويض أثناء تبادل الرمز.

إليك رسم بياني مبسط لتتابع تدفق رمز الإذن مع PKCE:

تم التوصية في البداية للعملاء العامين بـPKCE، ولكن OAuth 2.1 يمتد هذه التوصية إلى مطلب إلزامي لجميع العملاء، بما في ذلك العملاء السرية (الخاصة) .

المطابقة الدقيقة لعنوان URI لإعادة التوجيه

يتم استخدام عناوين URI لإعادة التوجيه بواسطة العميل لاستقبال ردود التفويض من خادم التفويض. يقدم OAuth 2.1 مطلبًا جديدًا بأن عنوان URI لإعادة التوجيه المستخدم في طلب التفويض يجب أن يطابق تمامًا عنوان URI لإعادة التوجيه المسجل من قبل العميل مع خادم التفويض (Authorization server) ، بما في ذلك المخطط، والمضيف، والمسار.

في بعض تنفيذات OAuth 2.0، كانت مطابقة عنوان URI لإعادة التوجيه متساهلة، مما يسمح بالمطابقات الجزئية أو استخدام الأحرف البديلة. ومع ذلك، فإن هذه المرونة يمكن أن تقدم مخاطر أمان، مثل ثغرات التوجيه المفتوحة.

تعريف واضح لأنواع العملاء

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

لذلك، يقدم OAuth 2.1 تعريفًا واضحًا لأنواع العملاء:

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

متطلبات الأمان لرموز التحديث

رموز التحديث هي رموز طويلة الأمد يستخدمها العميل للحصول على رموز وصول جديدة بدون تفاعل المستخدم. في نفس الوقت، هي أيضًا أهداف قيمة عالية للمهاجمين. حيث لا يمكن للعملاء العامين تخزين بيانات الاعتماد بأمان، يحدد OAuth 2.1 أن خادم التفويض (Authorization server) يجب أن يستخدم إحدى الوسائل التالية لتأمين رموز التحديث:

إصدار رموز تحديث مقيدة بالمرسل .
استخدام تدوير رموز التحديث لتقليل قابلية الاستخدام وعمر رموز التحديث.

OAuth 2.1 وOpenID Connect (OIDC)

حيث تم بناء OpenID Connect (OIDC) على قمة OAuth 2.0، فإن التغييرات المقدمة في OAuth 2.1 تنطبق أيضًا على OIDC. على سبيل المثال، ينبغي على جميع عملاء OIDC استخدام تدفق رمز الإذن مع PKCE للمصادقة وتفويض المستخدم.