قمنا في المقال الأول من سلسلة المصادقة والتخويل بالتعرف على مفهوم المصادقة، والتخويل، الحاجة لهما، واستعرضنا بعض الطرق لتطبيقهما.
هذه هي المقالة الثانية من السلسلة، حيث نركز هنا على المصادقة باستخدام الجلسة (session-based authentication) ونتعمق أكثر بقليل في تفاصيل تطبيقها، خاصة باستخدام ملفات تعريف الارتباط، ثم نتطرق الى كيفية تحقيق ذلك في تطبيقات الموبايل.
أنصحك بالاطلاع أولاً على المقالة الأولى من السلسلة ماهي مصادقة المستخدمين (user authentication)، وكيف تتم في الويب.
المصادقة باستخدام الجلسة (Session-based authentication)
الويب لا يتذكر الحالة أو السياق (Web is stateless)
رأينا في مقالة كيف يعمل الانترنت اعتماد الانترنت بشكل أساسي على بروتوكول HTTP (Hyper-text transfer protocol). يوصف بروتوكول HTTP بأنه غير متذكر للحالة (stateless). هذا يعني أنه تتم معاملة وتخديم كل طلب يُرسل من العميل (client) إلى المخدم (server) بشكل مستقل تماما عن غيره، أي بغض النظر عن كون هذا الطلب أول طلب أو ثاني طلب يٌرسل إلى المخدم، يقوم المخدم بمعاملة الطلب بنفس الطريقة ويعيد نفس النتيجة.
هذا السلوك مفيد في بعض الحالات، مثل موقع ويب ستاتيكي يقوم فيه المستخدم بطلب صفحة، ويحصل عليها، يستطيع أيضا التنقل من صفحة إلى أخرى.
الحاجة إلى تخزين الحالة (state) في طرف المخدم
السلوك "عديم الحالة" غير عملي في معظم تطبيقات الويب اليوم، فعادة ما يحتاج المخدم إلى تخزين معلومات (أو سياق) عن المستخدم الحالي. مثلا، في موقع تسوق الكتروني، يمكن أن يقوم المستخدم بتسجيل الدخول، هنا ينبغي على المخدّم بعدها معاملة جميع الطلبات اللاحقة على أنها مرتبطة بمستخدم قام بتسجيل دخوله.
افرض قيام المستخدم بإضافة منتج ما إلى سلّة الشراء، يجب على الموقع إضافة هذا المنتج إلى سلّة المستخدم، ويجب على الطلبات اللاحقة (مثلا عند الانتقال إلى صفحة أخرى، أو تحديث الصفحة) تذكّر قيام المستخدم بإضافة المنتجات، وإظهار ذلك.
كيف نستطيع تحقيق ذلك؟ باستخدام مفهوم الجلسة
الجلسة (Session)
الجلسة (session) هي عبارة عن كيان يتم إنشاؤه وتخزينه في المخدم (ربما على شكل ملف، أو مدخل في قاعدة بيانات، أو غير ذلك)، يتم من خلاله حفظ معلومات المستخدم وجلسته. قد تحتوي جلسة المستخدم على بعض أو كل من البيانات التالية (بالإضافة إلى بيانات أخرى):
- معرّف خاص للجلسة (Session ID) سنرى استخداماته
- معرّف المستخدم (User Id) للمستخدمين مسجلي الدخول
- تاريخ انتهاء صلاحية الجلسة
- الجهاز أو العميل (user device or agent)
- تاريخ ووقت آخر تفاعل مع الموقع
وغير ذلك من البيانات المحتملة.
بعد إنشاء الجلسه، يتم مشاركة معرف الجلسة فقط (Session ID) مع العميل (مثل تطبيق الموبايل، أو متصفح الانترنت) والذي يقوم بعدها بإرسال معرف الجلسة هذا إلى المخدم مع جميع الطلبات.
باستخدام معرف الجلسة هذا، يستطيع المُخَدِّم جلب معلومات جلسة المستخدم من قاعدة بياناته، بالتالي وضع كل طلب من طلبات العميل ضمن سياق، حيث يمكن معرفة المستخدم الذي أرسل الطلب، وأي معلومات أخرى مرتبطة.
الجلسات المعتمدة على ملفات تعريف الارتباط (Cookie-based sessions)
تعد أكثر طرق المصادقة انتشارا في مجال مواقع الانترنت. وهي تعتمد على ما يدعى ملفات تعريف الارتباط (cookies). سوف نتعرف على ملفات تعريف الارتباط بعد قليل، تابع معي خطوة بخطوة.
١: كيف تتم المصادقة باستخدام ملف تعريف الارتباط (cookie-based authentication)
أولاً: تسجيل الدخول إلى الموقع باستخدام كلمة السر
يستطيع المستخدم (الذي قام مسبقا بإنشاء حساب) تسجيل الدخول الى الموقع لتأكيد هويته، من خلال إدخال معرفه الشخصي (اسم المستخدم، أو البريد الالكتروني الذي استخدمه للتسجيل)، وكلمة السر (مفتاحه السري الذي يثبت أنه فعلا يملك هذا الحساب). يتم بعدها إرسال هذه البيانات الى المخدم. عادة ما يكون الاتصال مع المخدم مشفرا (باستخدام بروتوكول HTTPS/TLS) بالتالي لا ضرر من إرسال كلمة السر كما هي إلى المخدم عبر الشبكة.
ثانياً: التحقق من هوية المستخدم في طرف المخدم
بعد أن يستقبل المخدّم اسم المستخدم وكلمة السر، يقوم بمقارنة هذه البيانات مع ما هو مخزن في قاعدة بياناته، ويتحقق من تطابقها. في حال التطابق، يتم مصادقة واعتماد تسجيل الدخول، وإلا فيتم ارسال رسالة خطأ الى المستخدم تفيد بكون اسم المستخدم أو كلمة السر غير صحيحين.
معلومة: تعتبر من انتهاكات الأمان والخصوصية إخبار الزبون فيما إذا كان البريد المدخل مسجلُ أم لا، فهذا يسمح لأي مستخدم أو مستغل للثغرة بإيجاد (أو تعداد) مستخدمي الموقع. بل عادة ما يتم إخبار المستخدم بفشل تسجيل الدخول من دون تحديد كون المشكلة في عدم وجود حساب، أو بكون كلمة السر خاطئة.
ثالثاً: إنشاء وتخزين جلسة للمستخدم (user session)
بعد أن قام المخدّم بمصادقة المستخدم والتحقق من هويته، يقوم بتوليد جلسلة (session) وتخزينها في قاعدة بياناته. كما اطّلعنا أعلاه، يتم اعطاء هذه الجلسة رمز معرف (session id) ويتم تخزين معلومات المستخدم المرتبط بهذه الجلسة، كما ويتم عادة تحديد تاريخ انتهاء صلاحية الجلسة وتخزينه مع الجلسة.
من الآن فصاعدأ، يجب على جميع الطلبات الواردة من هذا المستخدم إلى المخدّم أن تحتوي على معرّف الجلسة. كيف يتم ذلك؟
رابعاً: إضافة معرف جلسة المستخدم (session id) الى المستعرض
بعد أن تم توليد وتخزين معلومات جلسة المستخدم في طرف المخدّم، يقوم المخدم بتخزين معرّف الجلسة (session id) في مستعرض الانترنت الخاص بالمستخدم ضمن ملف تعريف ارتباط (cookie).
ملفات تعريف الارتباط (cookies): هي عبارة عن قيم (key, value) يقوم المخدم (server) بتخزينها في مستعرض الانترنت (browser)، ويقوم المستعرض بإرسالها مع كل طلب إلى المخدم. تستخدم لتخزين بعض البيانات صغيرة الحجم في طرف المستخدم، مثلا: معرف جلسة المستخدم، هل قام المستخدم بالموافقة على سياسة الخصوصية للموقع؟ وبعض تفضيلات المستخدم الأخرى.
بما أن المستعرض يقوم بإرسال ملفات تعريف الارتباط إلى المخدم بشكل تلقائي، فسيستطيع المخدم من الآن فصاعدا الحصول على معرّف جلسة المستخدم (session-id) من ملف تعريف الارتباط المرفق مع كل طلب. وباستخدام معرف جلسة المستخدم (session-id) يمكن الحصول على كامل معلومات الجلسة من قاعدة البيانات، بما فيها معلومات المستخدم الذي تم انشاء هذه الجلسة من أجله.
وهكذا تقوم هذه الأنظمة بالسماج للمستخدم بتسجيل الدخول، تذكر هويته، والتعرف على مصدر جميع الطلبات الواردة من المستعرض الخاص بهذا المستخدم.
٢: كيف تعمل ملفات تعريف الارتباط؟
إذا ما راجعت مقالتي كيف يعمل الويب، ستعرف أن كل طلب (request) من المستعرض يرسل الى المخدم، يقابله استجابة (response) يرسلها المخدم إلى المستعرض.
ملفات تعريف الارتباط هي عبارة عن بيانات بسيطة الشكل، "يزرعها" المخدم في مستعرض الإنترنت، من خلال تمريرها في الاستجابة (response)، وتبقى في المستعرض حتى انتهاء صلاحيتها. يتم ربط هذه الملفات بنطاق (domain) معين، يمثل عادة نطاق الموقع الذي زرعها، بالتالي لن يتم ارسال ملفات تعريف الارتباط التي قام موقع "أفق" بتخزينها في مستعرضك إلى أي موقع أخر أبدا، لأنه تم اعداد هذه الملفات لموقع أفق فقط (من خلال ربطها بنطاق الموقع).
كما ويمكن تخصيص ملفات تعريف الارتباط هذه بحيث يتم منع الوصول إليها من الجافا سكربت (Javascript)، لزيادة عوامل الأمان وتقليل احتمالات قرصنة الموقع أو سرقة معلومات حساسة مثل معرفات الجلسة.
ملاحظة: إياك وأن تشارك محتويات ملفات تعريف الارتباط مع أي شخص كان، فقد يتم استخدامها لاختراق حساباتك.
إذاً، ما الذي حدث تماما عندما فتحت فيس بوك لآخر مرة؟
عندما قمت بكتابة facebook.com في شريط العناوين، و طلبت الموقع، قام المستعرض الخاص بك بإرسال طلب الى الموقع، يتمضن جميع ملفات تعريف الارتباط المرتبطة بالنطاق facebook.com.
عندما وصل الطلب الى المخدم، قام المخدم بقراءة هذه البيانات وباستخدامها حصل على معرف الجلسة (session-id) الذي تم توليده وتخزينه في مستعرضك من قبل. من خلال هذا المعرف قام الموقع باسترجاع كامل معلومات الجلسة بما فيها معلومات المستخدم، وهكذا استطاع معرفة أن الطلب قادم منك أنت. باستخدام هذه المعلومة، استطاع فيس بوك أن يعرض لك الصفحة الرئيسية بما يناسبك أنت.
والذي يحدث عندما تقوم بتسجيل الخروج هو ببساطة عملية ازالة الجلسة (او حذفها) من المخدم، وقد يتضمن هذا أيضا ازالة معرف الجلسة من ملفات تعريف الارتباط في متصفحك.
٣: مزايا وعيوب المصادقة باستخدام ملفات تعريف الارتباط
رأينا كيفية عمل المصادقة باستخدام ملفات تعريف الارتباط، وهي أكثر الطرق شيوعا ما بين مواقع الويب. شعبية هذه الطريقة أتت لعدد من الأسباب التي سأذكرها الآن، لكنها أيضا أتت مع مجموعة من العيوب والتي عادة ما تكون سهلة الحل، كما سنرى.
ميزات المصادقة باستخدام ملفات تعريف الارتباط
١- تعد من الطرق سهلة التطبيق، حيث تتضمن جميع متصفحات الانترنت اليوم دعماً تلقائيا لملفات تعريف الارتباط، بالتالي من السهل جدا على المخدّم تخزين معرف الجلسة في طرف المستخدم باستخدام هذه الطريقة، وبدون كتابة أي كود (Javascript)، كما وسيضمن ذلك إرسال هذا المعرف بشكل تلقائي الى المخدم.
٢- يمكن أن تعيش ملفات تعريف الارتباط لفترات طويلة جدا في متصفح المستخدم، مما يعني امكانية دعم جلسات مستخدم طويلة الأمد.
٣- يمكن تخصيص ملفات تعريف الارتباط (cookies) وإعدادها (configuration) لزيادة أمانها، مثلا من خلال استخدام خيارات مثل (HttpOnly) و (Secure) لمنع الوصول الى هذه الملفات من قبل الجافا سكربت. هذا يعني جعلها قابلة للكتابة والقراءة فقط من قبل المٌخدم.
عيوب المصادقة باستخدام ملفات تعريف الارتباط
١- أثناء استخدام المصادقة باستخدام ملفات تعريف الارتباط، يصبح الموقع عرضة لهجوم تزوير الطلبات عبر المواقع (Cross-Site Request Forgery or CSRF).
مثلا، افرض أن المستخدم قام بتسجيل دخوله والمصادقة باستخدام الـ cookie إلى موقع لديه رابط من الشكل التالي: https://website.com/articles/delete?id=1 والذي يقوم بحذف مقال للمستخدم.
يمكن أن يتعرض المستخدم لعملية احتيال حيث يتم إرسال الرابط السابق من خلال رسالة أو بريد الكتروني. في مثل هذه الحالات، بمجرد نقر المستخدم على الرابط يقوم الموقع بتنفيذ الطلب (حذف المقال)، لأنه سيكون قد قام بمصادقة المستخدم بشكل تلقائي (بما أن ملف تعريف الارتباط الخاص بالجلسة تم إرساله تلقائياً الى المخدّم)، وهذا سلوك غير مرغوب.
يمكن أن تحصل عملية الاحتيال هذه أيضا عند استخدام أنواع أخرى من الطلبات مثل POST (كما في هذا المثال) وهنا قد تكون الأمور أخطر، فمعظم العمليات الحساسة عبر الانترنت تحدث من خلال طلبات أخرى مختلفة عن GET.
على الرغم من أنه يمكن تطبيق الحماية من هجمات (CSRF)، كما أن العديد من منصات العمل (frameworks) توفر هذا بشكل سلس، إلا أن هذه الثغرة تبقى إحدى العيوب التي تعاني منها المصادقة باستخدام ملفات تعريف الارتباط، والتي يجب الانتباه إليها ومعالجتها.
٢- أقل توافقاً مع تطبيقات الموبايل الأصلية
لا تعمل المصادقة باستخدام ملفات تعريف الارتباط بشكل تلقائي على تطبيقات الهواتف المحمولة، بل يجب استخدام وسائل أخرى لتتبع الجلسة، كما سنرى في الفقرة التالية.
- أقل قابلية للتوسع
قد تكون المصادقة باستخدام ملفات تعريف الارتباط (والجلسة عموما) أقل قابلية للتوسع (less scalable) عندما يزداد حجم المستخدمين أو الضغط على المخدّم بشكل كبير جدا، فيما إذا ما قورنت مع الطرق الأخرى مثل استخدام رموز الويب المهيكلة (Json Web Tokens - JWTs) والتي سنتطلع عليها في المقالة التالية، مع ذلك فإنها تبقى عملية وفعالة في معظم التطبيقات.
ثانيا: الجلسات في تطبيقات الموبايل (Mobile app session)
تقوم تطبيقات الموبايل عادة بالتواصل مع المخدّم، أو واجهات برمجة البرامج (APIs) في المخدم باستخدام بروتوكول HTTP/HTTPS والذي رأينا أنه "لا يتذكر الحالة" (stateless).
لتجاوز هذا القيد، تقوم العديد من تطبيقات الموبايل باستخدام أسلوب مشابه لأسلوب مواقع الويب من خلال إنشاء جلسه للمستخدم عند قيامه بتسجيل الدخول وتخزينها في طرف المخدّم، قبل إرجاع معرف الجلسة (أو رمز معين) إلى تطبيق الموبايل. يقوم تطبيق الموبايل بتخزين هذا المعرف على الجهاز ويقوم بعدها بتمريره مع كل طلب إلى المخدّم، من أجل تحقيق المصادقة، وتطبيق الجلسة.
الفرق هنا أنه عادة لا يتم استخدام ملفات تعريف الارتباط (cookies)، فهي شيء يميز تطبيقات الويب وهي غير موجودة في تطبيقات الموبايل، بل يتم تمرير هذا الرمز إلى المخدم يدوياً من قبل التطبيق، عادةً من خلال ترويسات الطلب (Request headers).
يطلق أحيانا على معرف الجلسة هذا مصطلح رمز مبهم (opaque token) وهو يعني سلسلة عشوائية وفريدة من المحارف، يتم توليدها من قبل المخدم وتمريرها إلى العميل (agent) ليقوم باستخدامها من أجل المصادقة، التخويل، وتعريف الجلسة.
خلافا للرموز المبهمة (opaque tokens)، لدينا نوع مختلف من الرموز يدعى بالرموز المهيكلة (structured tokens)، مثل (JWTs). هذه الرموز وخلافا للرموز المبهمة تحتوي على معلومات مهيكلة قد تمثل معرف المستخدم، صلاحياته أو غير ذلك. سنتطلع على هذا النوع من الرموز بالتفصيل من خلال المقالة التالية من هذه السلسلة.
في الختام
اطلعنا من خلال هذه المقالة على أسلوب المصادقة باستخدام الجلسة (Session-based authentication)، وتعرفنا على أبرز الطلق لتطبيقه في كل من الويب وتطبيقات الموبايل.
سأتابع معكم في المقالة التالية بالحديث عن المصادقة باستخدام الرموز (Token-based authentication) مع التركيز على رموز الويب المهكيلة (JWTs).
وسأحاول لاحقا إضافة البعض من التطبيقات العملية لطرق المصادقة المختلفة التي تحدثنا عنها، ستجدون كل ذلك ضمن سلسلة المصادقة والتخويل. تابعو حسابي على أفق لتلقي الإشعارات عند نشر المزيد من المقالات.
