كيف يمكن تأمين تخزين الـ token وتسجيل الدخول بشكل آمن؟

تخزين token في localstorge ليس أمنًا بشكل كامل، لأنه يمكن لأي نص برمجي يعمل في المتصفح الوصول إلى قيمة token واستخدامها.

لذلك، ينصح بعض المصادر باستخدام ملفات تعريف الارتباط (cookies) بدلاً من localstorge، لأنها توفر خيارات أمان أكثر، مثل تحديد نطاق الملفات الشخصية أو جعلها غير قابلة للوصول من جافاسكربت، ومع ذلك فإن ملفات تعريف الارتباط ليست محصنة ضد الهجمات أيضاً.

لذلك، يجب دائمًا اتباع الممارسات الأمنية الجيدة عند التعامل مع token، مثل استخدام https وتحديد فترة صلاحية قصيرة والتحقق من صحة الطلبات.

لا يجب أبدًا تخزين الـ token في مكان عام مثل عنوان URL أو في ملفات JavaScript قابلة للعرض في المتصفح.

والأفضل تخزين الـ token في مكان آمن مثل مساحة تخزين محلية (مثل Local Storage) أو ملفات تعريف الارتباط Cookies، ولكن يجب الانتباه إلى النقاط التالية:

في حالة استخدام Local Storage: انتبهي إلى أنها قابلة للوصول عن طريق البرمجة النصية في الجانب العميل وقد تتعرض للهجمات مثل Cross-Site Scripting (XSS)، لذلك ينبغي التأكد من تأمين التطبيق بشكل جيد وتجنب الثغرات الأمنية المعروفة.

في حالة استخدام  Cookies فيجب تفعيل خاصية HttpOnly التي تمنع الوصول إليها من خلال البرمجة النصية في الجانب العميل، مما يقلل من خطر الاختراق الناتج عن هجمات XSS، كما يجب تشفير الـ token وتوقيعه بشكل صحيح لتجنب الاستيلاء عليه أي من خلال JWT.

وأسهل طريقة لتخزين الـ token بشكل آمن هي استخدام الـ Cookies مع خاصية HttpOnly.

فعند تعيين الـ token كقيمة لملف تعريف الارتباط، يتم تأمينها من الوصول الغير المصرح به عن طريق البرمجة النصية من جانب العميل، مما يعني أن الـ token لن يكون متاحًا للعميل من خلال JavaScript، وبالتالي يقلل من فرص استغلاله من قبل هجمات Cross-Site Scripting (XSS).

Web Storage (local storage/session storage):
عادةً، يتم وضع JWT في local storage للمتصفح وهذا يعمل بشكل جيد لمعظم الحالات.

عند تسجيل دخول المستخدم باستخدام اسم المستخدم وكلمة المرور، يتضمن جسم الاستجابة access_token JWT. بعد ذلك، تحتاج إلى التعامل مع هذا الاستجابة في كود الجانب العميل. يمكن حفظ هذا التوكن في localStorage أو sessionStorage.

كلاًّ من localStorage وsessionStorage يمتدان من Storage. الفرق الوحيد بينهما هو احتفاظ البيانات:

localStorage - تحتفظ البيانات حتى يتم حذفها بشكل صريح. يتم حفظ التغييرات التي تم إجراؤها وتتوفر لجميع الزيارات الحالية والمستقبلية للموقع.

sessionStorage - يتم حفظ التغييرات التي تم إجراؤها وتتوفر للصفحة الحالية، بالإضافة إلى الزيارات المستقبلية للموقع على نفس النافذة. بمجرد إغلاق النافذة، يتم حذف التخزين.

عيوب Web Storage:
على عكس الكوكيز، يكون الlocal storage محصورًا في نطاق محدد ولا يمكن الوصول إلى بياناته من أي نطاق آخر بما في ذلك النطاقات الفرعية. يمكن الوصول إلىWeb Storage عبر JavaScript في نفس النطاق، لذلك قد يكون عرضة لهجمات cross-site scripting (XSS).

يجب على المطور التأكد من إرسال التوكن دائمًا عبر HTTPS وليس HTTP.

استخدام الكوكيز:
يمكن أيضًا استخدام الكوكيز لتخزين التوكن. يختلف الطريقة الدقيقة لضبط الكوكيز اعتمادًا على لغة الجانب العميل التي تستخدمها.

هناك خيارات مختلفة للتحكم في مدة حياة الكوكيز:

يمكن تدمير الكوكيز بعد إغلاق المتصفح (كوكيز الجلسة).
يمكن تنفيذ فحص على الجانب الخادم (وعادة ما يتم ذلك من قبل إطار العمل الذي يتم استخدامه)، ويمكن تنفيذ انتهاء الصلاحية أو انتهاء الصلاحية المتزايدة.
يمكن أن يكون هناك صلاحية انتهاء للكوكيز  (لا تتم تدميرها بعد إغلاق المتصفح) 
يمكن قراءة الكوكيز من قبل كود JavaScript والكود الخادم أو فقط الكود الخادم إذا تم تعيين العلم httpOnly.
عيوب الكوكيز:
يبلغ الحد الأقصى لحجم الكوكيز 4 كيلو بايت فقط، لذلك قد يكون هذا مشكلة إذا كان هناك العديد من المطالبات المرفقة بالتوكن.
قد يكون الكوكيز عرضة للهجمات عبر الطلبات المزيدة (CSRF أو XSRF). يحدث هذا النوع من الهجمات عندما يتسبب موقع ويب خبيث في إجراء عمل غير مرغوب فيه على موقع موثوق به حيث يكون المستخدم مسجل الدخول حاليًا. وهذا يستغل كيفية تعامل المتصفح مع الكوكيز. يجعل استخدام حماية CSRF لإطار تطبيق الويب الخاص بك الكوكيز خيارًا آمنًا لتخزين التوكن. يمكن أيضًا الحد من CSRF بشكل جزئي من خلال فحص رأس HTTP Referer و Origin.

يمكن أن يكون استخدام الكوكيز صعبًا في حالة تطبيق يتطلب الوصول عبر النطاقات المختلفة. تتضمن خصائص الكوكيز (Domain/Path) التي يمكن تعديلها للسماح لك بتحديد مكان يسمح باستخدام الكوكيز.