OAuth 2.1 هنا: ما تحتاج إلى معرفته

المقدمة#

منذ إصدار OAuth 2.0 (RFC 6749) في عام 2012، تغير عالم تطبيقات الويب والموبايل كثيراً. ينتقل الناس من أجهزة الحاسوب المكتبية إلى الأجهزة المحمولة، وأصبحت التطبيقات الصفحة الوحيدة (SPAs) الآن هي الشائعة. لقد رأينا أيضًا ظهور العديد من الأطر التكنولوجية الجديدة للويب. مع كل هذه التغييرات، برزت التحديات الأمنية أيضًا. لمواكبة أحدث تقنيات الويب، تم إصدار RFCs جديدة مثل Proof Key for Code Exchange (PKCE) باستمرار لتعزيز OAuth 2.0. أصبح من الضروري تجميع جميع أفضل الممارسات لمتطلبات الأمان الحالية، وهذا هو السبب وراء قدوم OAuth 2.1.

في OAuth 2.1 القادم، تهدف مجموعة العمل على OAuth إلى دمج جميع أفضل الممارسات والتوصيات الأمنية في وثيقة واحدة. في Logto، نحن ملتزمون بأحدث المعايير وأفضل الممارسات لنظام OAuth. في هذه المقالة، سوف نستكشف الفروق الرئيسية بين OAuth 2.0 وOAuth 2.1 وكيف تم تبنيها في Logto.

PKCE مطلوب الآن لجميع عملاء OAuth الذين يستخدمون تدفق كود التفويض#

من أبرز التغييرات في OAuth 2.1 أن Proof Key for Code Exchange (PKCE) أصبح الآن مطلوبًا لجميع عملاء OAuth الذين يستخدمون تدفق كود التفويض. PKCE هو توسعة أمنية تمنع هجمات اعتراض كود التفويض. إنه مفيد بشكل خاص لتطبيقات الموبايل والتطبيقات الصفحة الوحيدة (SPAs) حيث لا يمكن تخزين سر العميل بشكل آمن.

يمكن تصنيف عملاء OAuth إلى نوعين مختلفين بناءً على قدرتهم على تخزين الأسرار بأمان:

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

2. العملاء العموميون: هؤلاء العملاء لا يستطيعون تخزين الأسرار بأمان، مثل التطبيقات الموبايل وSPAs. يمكن استخراج سر العميل بسهولة من كود الجانب العميل، ويصعب حمايته من المهاجمين.

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

يعمل PKCE عن طريق إنشاء محقق كود عشوائي وتحدي كود بناءً على محقق الكود. يتم إرسال محقق الكود إلى خادم التفويض، ويستخدم تحدي الكود للتحقق من محقق الكود عند تبادل كود التفويض للحصول على رمز الوصول.

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

في Logto، يتم تنشيط تدفق تحقق PKCE تلقائيًا لكل من العملاء العموميين والموثوقين.

بالنسبة لـ SPAs وتطبيقات الموبايل، يعد PKCE إجراءً أمنيًا لا بد منه لحماية تدفق كود التفويض في Logto. سيتم رفض أي طلب تفويض يفتقر إلى تحدي كود على الفور من خادم تفويض Logto.

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

مطابقة دقيقة لعناوين URL الخاصة بإعادة التوجيه#

عنوان URI (المرجع الموحد للموارد) لإعادة التوجيه هو نقطة نهاية أو عنوان URL محدد يقوم خادم التفويض بإعادة توجيه المستخدم إليها بعد اكتمال عملية التوثيق والتفويض.

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

تمت مقدمة المطابقة السلسلية الدقيقة لعناوين URI لإعادة التوجيه لأول مرة في أفضل ممارسات الأمان الحالية لـ OAuth 2.0 في القسم 4.1. تضمن هذه الممارسة أن عنوان URI لإعادة التوجيه يجب أن يطابق تمامًا مع العنوان المسجل لدى خادم التفويض. أي انحراف عن عنوان URI لإعادة التوجيه المسجل سيؤدي إلى استجابة خطأ.

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

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

تدفق ضمني أصبح مهملًا#

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

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

في أفضل ممارسات الأمان الحالية لـ OAuth 2.0 يُذكر بوضوح أن:

لا ينبغي للعملاء استخدام ترخيص الضمني (نوع الاستجابة "token") أو أنواع الاستجابات الأخرى التي تصدر رموز الوصول في استجابة الترخيص.

وبالتالي، تم إزالة تدفق الضمني رسميًا من مواصفات OAuth 2.1.

في Logto، يُعتبر تدفق كود التفويض مع PKCE هو التدفق المدعوم الوحيد لـ SPAs وتطبيقات الموبايل. يوفر تدفق كود التفويض طريقة آمنة أكثر للحصول على رموز الوصول من خلال تبادل كود التفويض.

طرح اعتماد كلمات المرور الخاصة بمالك الموارد أصبح مهملًا#

يسمح اعتماد كلمات المرور الخاصة بمالك الموارد (ROPC) للعميل بتبادل اسم المستخدم وكلمة المرور الخاصة بالمستخدم للحصول على رمز الوصول. تم تقديمه لأول مرة في مواصفات OAuth 2.0 كوسيلة لدعم التطبيقات القديمة مثل المصادقة الأساسية لـ HTTP أو التطبيقات الأصلية القديمة التي لا يمكنها استخدام تدفقات OAuth المؤمنة.

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

في وقت لاحق، في القسم 2.4 من أفضل ممارسات الأمان الحالية لـ OAuth 2.0، تم التأكيد بشكل أكبر على ضرورة عدم استخدام نوع اعتماد ROPC. نتيجة لذلك، تم إزالة نوع اعتماد ROPC من مواصفات OAuth 2.1.

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

نحن نفهم أن المطورين قد يرغبون في تصميم أو الاستضافة الذاتية لواجهة تسجيل الدخول الخاصة بهم لتحقيق أفضل تجربة للمنتج. في Logto، نقدم مجموعة متنوعة من خيارات تخصيص تجربة تسجيل الدخول (SIE)، بما في ذلك إعدادات العلامة التجارية وCSS المخصص. بالإضافة إلى ذلك، لدينا العديد من المشاريع الجارية، مثل جلب واجهة المستخدم الخاصة بك، وتسجيل الدخول المباشر، لتوفير المزيد من المرونة للمطورين لبناء واجهة تسجيل الدخول الخاصة بهم مع الحفاظ على أمان تدفق OAuth.

الخلاصة#

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