التصنيفات
Uncategorized

أساليب المصادقة الأكثر استخداماً في الـ API REST

هناك العديد من أساليب توثيق الاتصال وعمليات المصادقة ( authentication methods ) المستخدمة للحصول على صلاحيات او لتعريف هوية المستخدم عند التعامل مع الواجهات البرمجة ( REST APIs ) .
في هذا المقال سأحاول توضيح أكثر 3 طرق مصادقة استخداماً في عالم REST APIs و microservices world.

المصادقة مقابل الصلاحيات – Authentication vs Authorization

قبل ان نبداء دعونا نحاول التفريق بين المصادقة ( Authentication ) والصلاحيات الممنوحة للمستخدم بعد المصادقة ( Authorization )

بالعادة في الكثير من الانظمة يتم دمج الوظيفتين معاً بحيث انك مجرد ان عرفت عن نفسك ( Authentication ) تأخذ صلاحيات معينة للتعامل مع النظام ( Authorization ) لكن من الاسهل والافضل فصل الوظيفتين

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

الصلاحيات ( Authorization ) هو مفهوم مختلف تمامًا وبعبارة بسيطة ، يعبر عن مدى صلاحياتك للوصول والدخول لاماكن معينة او بيانات معينة في النظام .

ملخص:
المصادقة: يشير إلى إثبات الهوية الصحيحة
الصلاحيات: تشير إلى السماح بإجراء معين

الآن وبعد أن عرفنا ماهية المصادقة ، دعنا نرى ما هي طرق المصادقة الأكثر استخدامًا في واجهات برمجة تطبيقات REST APIs.

3 طرق المصادقة الأكثر استخداماً

1 – المصادقة عبر برتوكول HTTP

المصادقة عبر الـ HTTP لها عدة انواع سنتطرق لاثنين منها
١-
المصادقة الأساسية – Basic Authentication
٢-
مصادقة حامل الرمز – Bearer Authentication

المصادقة الأساسية – Basic Authentication

* لا يوصى باستخدام بروتوكول HTTP الأساسي للمصادقة نظرًا لوجود ثغرات أمنية فيه.

هذه هي الطريقة الأكثر سهولة ومباشرة. بهذه الطريقة ، يتم ارسال اسم مستخدم و كلمة المرور في الـ ( request header ).
ويتم تشفير اسم المستخدم وكلمة المرور باستخدام Base64 ، وهو أسلوب تشفير يحول اسم المستخدم وكلمة المرور إلى مجموعة من 64 حرفًا لضمان النقل الآمن.

لا تتطلب هذه الطريقة ملفات تعريف الارتباط ( cookies ) او جلسات ( session ) أو صفحات تسجيل الدخول وغيرها من الحلول المتخصصة ، لأنها تستخدم الـ HTTP header نفسه لارسال البيانات ، فليست هناك حاجة إلى المصافحة مع الخادم ( handshakes ) أو أنظمة الاستجابة المعقدة الأخرى.

مثال على ارسال البيانات عبر الـ HTTP header
Authorization: Basic bG9sOnNlY3VyZQ==

مصادقة حامل الرمز – Bearer Authentication

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

يجب على العميل إرسال الرمز المميز عبر الـ HTTP header تقديم او ارسال اي طلب للسيرفر:


Authorization: Bearer <token>

على غرار المصادقة الأساسية ، يجب استخدام مصادقة Bearer فقط عبر اتصال مشفر وامن ( SSL )

2 – مفاتيح الواجهة البرمجية – API Keys

تم إنشاء اسلوب المصادقة عبر مفاتيح الواجهة البرمجية (API) كحل لإصلاح مشكلات المصادقة المبكرة لـ HTTP Basic Authentication وأنظمة أخرى مماثلة. في هذه الطريقة ، يتم تعيين قيمة فريدة تم إنشاؤها لكل مستخدم لأول مرة ، مما يدل على أن المستخدم معروف. عندما يحاول المستخدم إعادة الدخول للنظام ، يتم استخدام مفتاحه الفريد لإثبات أنه المستخدم نفسه .

احياناً يتم إرسال العديد من المفاتيح كجزء من الـ URL عند طلب الخدمة ، مما يجعل من السهل اكتشافها بالنسبة لشخص لا ينبغي أن يكون له حق الوصول إليها. لذلك يجب عدم تمرير المفاتيح عبر الرابط ( URL params ) لانها ببساطة قابلة للقراءة من طرف ثالث! الخيار الأفضل هو وضع مفتاح API في الـ ( Authorization header ). على النحو التالي :
Authorization: Apikey 1234567890abcdef.

هناك بالتأكيد بعض الحالات من الجيد فيها استخدام API Keys.
أولاً وقبل كل شيء لانها بسيطة وسهلة الاستخدام . ففي الحالات التي لا تعد فيها الحماية والامان معيار مهم جداً على سبيل المثال ، إذا كانت واجهة برمجة التطبيقات (API) لها وظيفة واحدة وهي القراءة “read” ، يمكن أن يكون مفتاح API حلاً مناسبًا. بشرط ان لا يكون هنالك امكانية التعديل أو الحذف .

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

الرجاء التفكير ملياً في امان النظام قبل استخدام هذه الطريقة

3.  برتوكول التفويض المفتوح ( OAuth 2.0 )

كانت الإصدارات السابقة من هذا البرتوكول ، OAuth 1.0 و 1.0a ، أكثر تعقيدًا من OAuth 2.0. ففي اخر نسخة من هذا البرتوكول تم اسقاط الكثير من المتطلبات منها ان كل طلب كان يحتاج لرقم مشفر ( keyed hash ) وتم استبدالها باحد الخيارات التالية :

  • رمز الوصول ( access token ): يتم إرساله بنفس طريقة مفتاح API ، وهو يتيح للتطبيق الوصول إلى بيانات المستخدم, يمكن اختيارياً تحديد مدة صلاحية معينة للمفتاح.
  • رمز الوصول محدث ( refresh token ): هو جزء اختياري في البرتوكول في حال تم تعيين مدة صلاحية للمفتاح وانتهت يتم انشاء هذا المفتاح .

يعد OAuth 2.0 هو الخيار الأفضل لتحديد هوية المتسخدمين ومنح الأذونات المناسبة لهم للتعامل مع النظام . في هذه الطريقة ، يقوم المستخدم بتسجيل الدخول إلى النظام. سيطلب ذلك النظام المصادقة ويعيد الطلب للمستخدم. ثم يقوم المستخدم بإعادة توجيه هذا الطلب إلى خادم مصادقة مستقل ( authorization server ) ، والذي يرفض هذا المصادقة أو يسمح به ، في حال السماح يتم ارسال رمز المصادقة ( access token ) لمقدم الخدمة فيصبح المستخدم الان مخول للدخول للنظام

يمثل المخطط التالي سير العملية

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

ملخص

في الوقت الحالي ، الفائز الواضح في الطرق الثلاث هو OAuth 2.0 ، وهناك بعض حالات الاستخدام التي قد تكون فيها مفاتيح واجهة برمجة التطبيقات ( Api Key’s ) أو أساليب مصادقة HTTP مناسبة حسب النظام ودرجة الامان المطلوبة .


اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *