من أبرز الأمور التي يجب على مبرمج المواقع و مختصي أمن المواقع فهمها بالتفصيل هو ال Authentication و كل ما يتعلق به: sessions - cookies - tokens vs session و غيرها..
و هذا ما سأحاول توضيحه في هذه السلسلة:
و هذا ما سأحاول توضيحه في هذه السلسلة:
أولا ما هو ال Authentication؟ باختصار هي عملية التحقق من المستخدم عن طريق إرسال ال username و ال password من صفحة تسجيل الدخول و من ثم يكون المستخدم قادرا على تنفيذ مجموعة من الأمور بناءً على ذلك،
و حتى يتم هذا التحقق فهو يتطلب بروتوكول (طريقة) معينة بين ال client و server 👇🏻
و حتى يتم هذا التحقق فهو يتطلب بروتوكول (طريقة) معينة بين ال client و server 👇🏻
لتنفيذ ذلك في مواقع الانترنت عموما يتم الاعتماد على ال session و هو عبارة عن جدول في قاعدة البيانات، بحيث يتم فيه تخزين رمز عشوائي للمستخدم الذي قام بتسجيل دخوله و الاعتماد على هذا الرمز (و هو ال session_id) للتحقق من هذا المستخدم، هذا هو التعريف العام لكن كيف يتم الأمر بالتفصيل؟
عندما يقوم المستخدم بإرسال ال username و ال password يقوم ال server بالتأكد من توفر مستخدم بهذه البيانات في قاعدة البيانات، و في حال العثور عليه فإن المطابقة صحيحة حينها يقوم ال server بإنشاء رمز عشوائي يسمى بال session_id
يتم حفظ هذا ال session_id في قاعدة البيانات بحيث يكون مرتبطا مع المستخدم بكامل بياناته في جدول المستخدمين، و يتم إرسال هذا ال session_id إلى ال client أو المتصفح حتى يتسنى للمتصفح معرفة الرمز الذي يمثل هذا المستخدم من الآن فصاعدا.. و بالتالي يقوم المتصفح بحفظ هذا الرمز
هذا الرمز يتم حفظه في المتصفح بحيث يكون مرتبطا مع ال domain الخاص بالموقع فلا يتم استخدامه أو إرساله في ال requests القادمة إلا إذا كان ال request متوجها لنفس ال domain و بمعنى آخر لنفس السيرفر الذي قام بإنشاء هذا ال session_id لتمييز هذا المستخدم عن غيره و التحقق منه
هذه البيانات المحفوظة بهذه الطريقة في المتصفح هي ما تسمى بال cookies..
إذا ماهي ال cookies؟ هي مجموعة من البيانات الخاصة بالمستخدم في موقع (domain) معين، بحيث يتم حفظها في المتصفح و يتم إرسالها كجزء من أي request يتم إرساله إلى هذا الموقع تحديدا
إذا ماهي ال cookies؟ هي مجموعة من البيانات الخاصة بالمستخدم في موقع (domain) معين، بحيث يتم حفظها في المتصفح و يتم إرسالها كجزء من أي request يتم إرساله إلى هذا الموقع تحديدا
الفكرة أن أي عملية (action) يقوم بها المستخدم بعد تسجيل الدخول يجب فيها أن يتم التحقق من هوية المستخدم و أنه مخول بالفعل لهذا الإجراء.. تخيل أن المستخدم ضغط على زر لتعديل اسمه في الموقع.. فكيف نتأكد أن هذا المستخدم بالفعل هو صاحب هذا الحساب الذي يريد تعديل اسمه فيه؟
سيتم إرسال طلب إلى السيرفر لتعديل الحساب (request) و كما ذكرنا فإن ال cookies المحفوظة في المتصفح لهذا الموقع سيتم إرسالها كذلك كجزء من هذا ال request و أحد أهم البيانات التي تم حفظها وقت تسجيل الدخول و بعد التحقق هو ال session_id
و بالتالي سيستقبل ال server هذا ال request المحمل بال session_id و أول ما سيقوم السيرفر بفعله هو التأكد هل هذا ال session_id هل هو مخزن في قاعدة البيانات؟ في حال تم العثور عليه سيقوم السيرفر بجلب كامل بيانات المستخدم الموجودة في قاعدة البيانات و سيقوم بتعديل الاسم حسب ال request
لاحظ كيف أن طريقة التحقق في أول مرة كانت تعتمد على ال username و ال password لكن تم مقايضتهما برمز معين (session_id)، و الذي أصبح يمثل مفتاحا لغرفة خاصة بهذا المستخدم في ال backend بحيث لايمكن للمستخدم الدخول للغرفة و الاطلاع على مافيها أو تغيير ما فيها دون استخدام هذا المفتاح
هذه الطريقة المعتمدة على ال session و ال cookies هي الطريقة التقليدية المعتمد عليها في مواقع الإنترنت للتأكد من هوية المستخدم و أحقيته في إجراءات معينة، لكن ماذا عن التطبيقات و المواقع (المنفصلة) التي تستخدم ال API؟ كيف يتم التحقق فيها من المستخدم؟
التطبيقات و المواقع المنفصلة (SPA) هي كذلك واجهات متصلة (بشكل غير مباشر) في نهاية الأمر بالسيرفر و لكن عن طريق وسيط و هو ال API، انفصالها عن السيرفر يصعب من الاعتماد على ال session-cookie للتحقق من المستخدم، فما الحل إذا؟
الحل هو استخدام ما يعرف بال token و هو شبيه إلى حد كبير بالطريقة التي يعمل فيها ال session_id مع بعض الاختلافات في التفاصيل، و بالتالي يتم إرسال ال username, password عند تسجيل الدخول كالعادة، و يتم التحقق منه كالعادة في قاعدة البيانات و في حال نجاح التحقق.. 👇🏻
في حال نجاح التحقق يقوم السيرفر بإنشاء ما يعرف بال token و هو رمز يتم استخدامه من ال client (الموقع أو التطبيق) كمفتاح لأي إجراء لاحق (action) عن طريق إرساله كجزء من ال request إلى السيرفر في كل مرة بعد تسجيل الدخول ليتم تمييز المستخدم
الفرق الحقيقي بينهما أن السيرفر في هذه الحالة فقط يتحقق من ال token المرسل و أنه صالح، دون جلب بيانات المستخدم المرتبطة بهذا ال token مما يجعل عملية التحقق أسرع لأن العبء تم تخفيفه على السيرفر
البيانات المتعلقة ب(الجلسة الحالية) للمستخدم - مثال: المنتجات المضافة لعربة التسوق في متجر الكتروني-
في حالة ال session-cookie يتم حفظها في قاعدة البيانات و يقوم السيرفر بجلبها في كل مرة يصل له ال session_id
أما في حالة ال token فهي تحفظ في ال client نفسه، لاحظ كيف ريحنا السيرفر
في حالة ال session-cookie يتم حفظها في قاعدة البيانات و يقوم السيرفر بجلبها في كل مرة يصل له ال session_id
أما في حالة ال token فهي تحفظ في ال client نفسه، لاحظ كيف ريحنا السيرفر
هل تذكر مثال الغرفة الممتلئة بالبيانات لكل مستخدم و مفتاحها هو ال session_id؟ الآن لا يوجد غرف بالسيرفر لتعبئة بيانات الجلسات لكل مستخدم، بل تحفظ البيانات في جهاز المستخدم نفسه
و بناءً على ذلك.. تعتبر طريقة ال token أكثر قابلية للتوسع (scalable)، لأنك عندما تصل لعدد هائل من المستخدمين فسيتم حفظ بيانات الجلسة في أجهزة هؤلاء المستخدمين بدلا من حفظها في ال server
تجدر الإشارة إلى أن الاعتماد على ال token يتم بعدة طرق لكن أشهرها هو ما يعرف بال (jwt: json web token) و الأخرى هي OAuth حيث تشتركان في مبدأ العمل مع بعض الاختلافات في التفاصيل التي لا يسع المجال لذكرها الآن
كلتا الطريقتين لهما جوانب إيجابية و سلبية و حالات معينة للاستخدام،
و في النهاية.. أتمنى أن أكون أضفت لك شيئا في هذه السلسلة، و إن فعلت فأرجو منك نشرها بالرتويت و الإعجاب للتغريدة الأولى بها 👇🏻..
و بالعافية عليك الكوكيز 🍪🌷
و في النهاية.. أتمنى أن أكون أضفت لك شيئا في هذه السلسلة، و إن فعلت فأرجو منك نشرها بالرتويت و الإعجاب للتغريدة الأولى بها 👇🏻..
و بالعافية عليك الكوكيز 🍪🌷
جاري تحميل الاقتراحات...