API Basics pt.4: Authentication - Arabic

by Moh Ayman | 12, August 2020

API

اتعرفنا المقال السابق على طريقة التواصل بين الـ Client والـ Server و لغات تبادل المعلومات مبينهم ... بس ازاي الـ Server يعرف ان الـ Client هو الحقيقي مش اخر, يعني لما تطلب من Web Server انه يظهرلك معلومات محددة ازاي الـ Server يتاكد من هويتك كـ Client … هنعرف ازاي بالمقال الحالي.

تقدر تروح للعناوين بسرعة من هنا, متخفش من العدد, بعض العناوين سطرين فقط:

 

Credentials

هي البيانات الـ انت بتوفرها كـ User بتستخدم في الـ Log-In Form زي اسمك والرقم السري ...  البيانات بيستخدمها الـ Client (زي الـ Web Browser) عشان يطلب من الـ Server توفير البيانات بناءا على تأكيد الهوية.

مثال, لما تعمل Log-in في الـ Facebook بتدخل الـ Credentials والـ Web Browse بيبعت لـ Facebook Server يطلب البيانات الخاصة بك (User)

 

Authentication

عملية تاكيد الهوية بين الـ Client والـ Server بواسطة الـ Log-In وبعدها السماح بإظهار البيانات اسمها Authentication

يعني لما Facebook Server راجع الـ Credentials ولاقها متوافقة (Match) مع بيانات User كان عامل تسجيل على الموقع قبل كده, أظهر البيانات الخاصة بالـ User ده.

 في عدة اشكال مختلفة من الـ Authentication بيستخدمها الـ API وتسمى Authentication Schemes.

 

Basic Auth

الطريقة المذكورة بالاعلى (توفير الاسم والرقم السري) هي ابسط شكل من الـ Authentication Schemes, واسمها Basic Authentication أو Basic Auth كاختصار.

 

Authorization Header

الـ Basic Auth بيطلب الاسم والرقم السري فقط ... الـ Client بياخد الاسم والرقم السري ويشفره كقيمة واحدة زي كده ZGVtbzpwQDU1dzByZA ويبعتهم في الـ HTTP Request خلال Authorization Header.

الـ Server بيستقبل الـ Request ويشوف الـ Authorization Header ويقارن بينه وبين الـ Credentials المخزنة ... لو كان في Match, بيظهر البيانات المطلوبة ولو مفيش Match بيبعت Status Code برمز 401 والتي تعني ان الـ Authentication (تاكيد الهوية) فشل والـ Request اترفض.

 

Basic Auth Vulnerability

الـ Basic Auth ضعيفة بسبب طبيعة الـ User ... الـ User بيستخدم نفس الـ Password على اكثر من موقع الكتروني, فرضا ان هو عمل حساب على Facebook, نسبة ان هو يستخدم نفس الـ Password مرة ثانية على موقع إلكتروني آخر محتاج Log-in زي G-mail مثلآ, كبيرة جدا.

 

Vulnerability no.1

بردو ايه المشكلة؟ … سنة 2010 موقع اسمه Gawker تم اختراقه بواسطة Hackers, وتم الكشف عن بيانات والارقام السرية للمستخدمين ... الـ Hackers جربو انهم يستخدمو نفس الـ Passwords دي عشان يخشو على مواقع تانية حساسة زي Facebook, Gamil و eBay, ونجحوا, واصبح عنده تحكم كامل في بيانات المستخدمين مش بس على Gawker.

فكرة انك تخلي المستخدمين ميستخدمش نفس الرقم السري اكثر من مرة يعتبر نص المشكلة, بجانب انها مستحيلة لان طول ما المستخدم هيبقى عاوز يعمل حساب على موقع تاني احتمالية استخدام نفس الرقم السري كبيرة جدا.

النص التاني, من المشكلة هي تخزين الرقم السري بامان ... لما المستخدم يعمل Log-In للموقع, بيكون محتاج يعمل Authentication مع الموقع وبالتالي الموقع هيبقي محتاج نسخة من الـ Credentials مخزنها عشان يعمل Match بينها وبين الـ Credentials الـ مدخله الـ User.

ممكن يتم تخزين الاسم والرقم السري بقاعدة البيانات بس كده بتعرض ان تخسر البيانات نتيجة Bug في الـ App او انك ممكن تتعرض للاختراق وتعرض بيانات الـ Users للتسريب.

 

Vulnerability no.2

مشكلة كمان … فكرة امكانية ولوج المستخدم للبيانات بشكل كامل بيعرض بيانات الـ Server لخطر, حيث ان الـ User الـ عمل Log-In ممكن يمسح اكونت او يغير الارقام السرية لمستخدمين تانيين والـ هي من صلاحيات الـ Admin او صاحب الـ Server.

لمعالجة المشكلتين السابقتين بنستخدم Authentication Scheme اسمه API Key Authentication.

 

Authorization VS Authentication

قبل الـ API Key Authentication هنراجع بسرعة الفرق بين Authorization والـ Authentication عشان نتاكد من سبات فهم الفرق مابينهم.

 

Authentication

هي التوافق بين الـ Credentials الـ بيوفرها الـ Client بعد ما الـ User يدخلها وبين الـ Credentials سابقة التخزين على الـ Server, الـ خطواتها كالتالي:

  • الـ User بيكتب الاسم والرقم السري (الـ Credentials) في الـ Log-In Form.
  • الـ Client (متصفح الانترنت) بياخد الـ Credentials ويبعنهم للـ Server في الـ HTTP Request Header اسمه Authorization Header.
  • الـ Server بيراجع الـ Credentials ويشوف اذا كانت متوافقة مع البيانات (Credentials) الـ كانت متخزنة عنده قبل كده, عملية المراجعة اسمها Authentication.

لو تم الـ Authentication بنجاح بنيجي للتعريف التالي

 

Authorization

هي سماح الـ Server باظهار البيانات المتخزنة على الـ Server ... بعد فهم الفرق نكمل حل مشكلة الـ Basic Auth Vulnerability 

 

API Key Authentication

ميزة الـ API Key Authentication Scheme انه بيضيف خطوة لتأكيد هوية الـ User فبدل ما يكون الاعتماد الاساسي على الـ Password الـ هيستخدمه الـ User ونواجه احتمالية الـ Vulnerability no.1 الـ Server هيديله رقم سري طويل ومعقد بحيث يكون صعب اعادة تكراره.

بالاضافة لحماية بيانات المستخدم تم حل الـ Vulnerability no.2 , بحيث ان كل API Key بيكون لجزء معين من البيانات, يعني باستخدام الـ API Key بيتم التفريق بين صلاحيات الـ User والـ Admin.

لما الـ Client بـ Authenticate باستخدم الـ API Key, الـ Server بيظهر البيانات ولكن مع وظائف محدودة متمكنش الـ User انو يتلاعب ببيانات الـ Users الآخرين

 

HTTP API Key Header

على عكس الـ Authorization Header الـ بيستخدمه الـ Client للتعامل مع الاسم والرقم السري للمستخدم, الـ API Key ملهوش Header.

الطريقة ان الـ Key يضاف بنهاية الـ URL كـ Parameter زي كده http://example.com?api_key=my_secret_key ودي الطريقة الأكثر شيوعا واستخداما.

 

النهاية

عرفنا ازاي الـ Client بيوكد هويته للـ Server بواسطة عملية اسمها Authentication ... واتعرفنا على نوعين من الـ Authentication Schemes

اهم المصطلحات

  • Authentication: عملية تاكيد الهوية بين الـ Client والـ Server.
  • Credentials: بيانات الـ User الـ بيوفرها للـ Client.
  • Basic Auth: ابسط انواع الـ Schemes بيعتمد على الاسم والرقم السري.
  • API Key Auth: نوع من الـ Schems بيطلب توفير Key بجانب الـ Credentials.
  • Authorization Header: الـ HTTP Request Header بيستخدمه الـ Client لتوفير الـ Credentials.

المقال التالي: Open Authorization - OAuth

مجموعة المقالات كاملة:

 

المراجع
Zapier
Smashingmagazine