أستراتيجيات حفظ الجلسة (JWTs, Database Session)
Mohanad Alrwaihy
April 16, 2023
174
2
عندما يقوم المستخدم بتسجيل الدخول إلى موقع ويب ، يجب حفظ جلسة عمل المستخدم من أجل تأكيد الطلبات المستقبلية من المستخدم والاستمرار في جلسة عمل المستخدم في موقع الويب لفترة زمنية محدودة.
6 دقائق للقراءة
عندما يسجل مستخدم الدخول لموقع ألكتروني فأن معلومات الجلسة تحفظ من اجل أي عمليات تتم عن طريق المستخدم في المستقبل ومن أجل الحفاظ على جلسة المستخدم في الموقع لمدة معينة من الوقت
المقصود من الجلسة (Session) هيا معلومات تسجيل المستخدم للموقع المراد وقد يكون تسجيل الدخول بأكثر من طريقة مثل أسم المستخدم وكلمة السر أو بأستخدام OAuth وعن طريقه يمكن تسجيل الدخول عن طريق مواقع أخرى مثل Google, Twitter, Facebook وغيرها من الخيارات. ومعلومات الجلسة هيا ربط بين المستخدم وبين طريقة تسجيل الدخول التي قام بها بحيث أي عمليات يقوم بها المستخدم في الموقع يتم التعرف من خلالها عن المستخدم الحالي 👍
أستخدام الJSON Web Tokens (JWTs)
في الJWTs البيانات تحفظ ك كائنJSON في جهة المستخدم (Client Side) وبمجرد ما تنشئ في السيرفر سوف تحتوي على ثلاثة عناصر وهيا الرأس, المحتوى, والتوقيع.
العناصر الثلاثة تفصل بين بعضها بأستخدام نقطة:
MARKDOWNxxxxx.yyyyy.zzzzzرأس الJWT
- خوارزمية التوقيع المستخدمة - معلومات عن خوازميات التوقيع
- نوع الترميز ويكون JWT.
JSON{
"alt": "HS256",
"typ": "JWT"
}حمولة الJWT
حمولة الJWT يتكون من معلومات عن المطالب بالمعلومات (بالعادة يكون المستخدم) ومعلومات أضافية. وتحتوي على ثلاثة انواع من المطالبة وهيا:
- المسجل - هذه قائمة بمعلومات يتم أستعمالها بكثرة في المطالب:
- iss (المسجل)
- exp (تاريخ الأنتهاء)
- sub (الموضوع)
- aud (الجمهور)
- عامة - يعرف من يستخدم الJWT.
- خاصة - مطالب خاصة تنشئ لتبادل المعلومات بين الطرفين.
JSON{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}توقيع الJWT
التوقيع ينشئ عن طريق أخذ الرأس المشفر والحمولة المشفرة وكلمة سر خاصة ويتم توقيع ذلك.
التوقيع يتسخدم لأثبات انه الرسالة لم يتم التعديل عليها وأثبات مرسل الJWT.
التوقيع بأستخدام خوارزمية HMAC SHA256:
JSONHMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)مزايا الJWT
- ليس من الضرورض وجود قاعدة بيانات لحفظ معلومات الجلسة وهذا يؤدي الى بناء أسرع وأرخص.
- الJWTs محمية بأستخدام طرق تشفير ممتازة لحفظ معلومات الجلسة ومعلومات أضافية بداخل الJWT Session Token.
- حفظ معلومات اضافية خاصة بالمستخدم وبما أن الJWT محفوظ في كوكيز يقرأ فقط عن طريق السيرفر (HTTP Cookie) هذا يؤدي انه المعلومات صعب أختراقها عن طريق JavaScript يعمل في الموقع.
سلبيات الJWT
- الJWTs صعب في عملية الأنتهاء لأنه يحتاج الى قائمة بالرموز الغير صالحة و يحتاج أنه يبحث في هذه القائمة كل ينشئ فيها رمز جديد (يتم تفادي المشكلة قليلا عن طريق تقليل تاريخ أنتهاء الجلسة.)
- البيانات محصورة بالCookie والتي بدورها تستطيع حفظ ما يقارب 4Kb لكل Cookie (هذه القيمة قد تختلف من متصفح لأخر لكن لدعم جميع المتصفحات يجب التأكد انها لا تزيد عن ذلك).
- المعلومات المشفرة قد يتم الكشف عنها في وقت ما حتى لو كانت محمية بشدة لا يجب الأفتراض ان عملية فك التشفير مستحيلة لأنه في أي وقت في المستقبل قد يتم الكشف عن ثغرة معينة او تطور في التقنية يؤدي الى فك تشفير المعلومات.
جلسات قاعدة البيانات (Database Session)
عند أستخدام Session Token معلومات مصادقة المستخدم تحفظ في قاعدة البيانات وتحتوي على هذه المعلومات:
- المعرف الأساسي - وهيا قيمة عشوائية (UUID) للتفريق بين الجلسات الموجودة.
- معلومات المستخدم User ID - يتم التعريف عن الUser ID في الجلسة لمعرفة والتحقق من المستخدم.
- بداية وقت الجلسة.
- نهاية وقت الجلسة.
- معلومات اضافية - بأمكاننا اضافة اي معلومات اضافية في الجلسة.
مزايا الSession Token
- المزيد من التحكم - يمكن أن تحتوي الجلسة المحفوظة في قاعدة بيانات على المزيد من الخيارات للجلسة ومعلومات إضافية مع مساحة أكبر.
- استهلاك البيانات - يستخدم القليل من البيانات لأنه يرسل معرف الجلسة فقط بدلاً من JWTs حيث يحتوي الJWT على الحمولة التي قد تكون كبيرة أو تزيد بمرور الوقت.
- رؤية البيانات اكثر أمانا- نظرًا لأن معرف الجلسة هو البيانات الوحيدة المتاحة في الCookie ، فلا توجد فرصة لتسريب أي معلومات أو في حالة JWT حيث يمكن لأي شخص قراءتها أو الحصول على فكرة عن كيفية هيكلة البيانات.
الاختيار الصحيح JWTs أو جلسات قاعدة البيانات 🤔
هناك الكثير من العوامل لتحديد أيهما أفضل لتطبيقك ولكن أولاً دعونا نلقي نظرة على الاختلافات بين هاتين الطريقتين:
- JWTs أسرع - لأنه لا يتطلب قاعدة بيانات وتخزين معلومات الجلسة.
- رمز الجلسة أكثر أمانًا - نظرًا لأن الجلسة تضمن أن تكون لمستخدم معين يسهل تنفيذ طلبات المستخدم وتفويضها.
لتحديد الخيار الأفضل ، يمكننا إلقاء نظرة على هذه الأسئلة والإجابة عليها وفقًا لذلك لمعرفة الخيار الأفضل:
1. ما مدى حساسية المعلومات؟
لتطبيق مثل بنك أو وكالة حكومية لديها معلومات حساسة للغاية. قد تكون جلسات قاعدة البيانات أفضل طريقة لضمان انه اي اتصال لديه أذن.
2. ما هي قابلية تطبيقك للتطوير؟
يعد التحجيم أسهل بكثير مع JWTs لأنه لا حاجة إلى مكالمات متكررة للخادم لإعادة مصادقة الجلسة.
3. الميزات الحديثة المستخدمة في تطبيقك؟
عند أستخدام ميزات حديثة في الويب مثل الحوسبة بدون خادم ، والوظائف عبر النطاقات ، أو تطبيق خاص بالجوال أو صفحة واحدة (SPA) يفضل أستخدام JWTs.
4. ما مدى أهمية الأداء ووقت التشغيل؟
هل يحتاج تطبيقك إلى توفير تجربة أسرع للمستخدمين؟
- الخدمات الحية Live Services - الخيار اللأفضل هوا أستخدام JWTs.
تطبيق آخر حيث لا يمثل تأخر الأتصال مشكلة للمستخدم النهائي ، يمكن أن تكون جلسات قاعدة البيانات خيارًا أفضل.
الجمع بين JWTs وجلسات قاعدة البيانات 😮
نظرًا لأن معظم الأشخاص سيقترحون دائمًا الاستخدام بين إحدى أدوات إدارة الجلسة هذه ، فقد كانت هناك بعض عمليات التنفيذ باستخدام كليهما عن طريق إرجاع رمز الجلسة و JWT عندما يبدأ المستخدم جلسة.
- رمز الجلسة - القيمة الثابتة طوال عمر الجلسة ( مخزنة في قاعدة بيانات ).
- JWT - وقت انتهاء الصلاحية قصير العمر.
الفكرة هي أنه يمكن تمرير JWT إلى واجهة برمجة التطبيقات للجلسة لاسترداد JWT جديدة عند انتهاء صلاحيتها والتأكد من أن رمز الجلسة لا يزال نشطًا قبل إرجاع JWT جديد.
مزايا استخدام هذه الطريقة هي أنه بدلاً من تفويض جلسة المستخدم لكل طلب باستخدام Session Token الذي يستغرق وقتًا. JWT سيتم استخدامه للتفويض الذي يقلل بشكل كبير من الأداء العام مع حمايتك أنت والمستخدمين النهائيين.
تستفيد هذه الطريقة من كل من Session Token Security 🔒 مع JWT Performance ⚡.
أستخدام NextAuth مع JWTs أو جلسات قاعدة البيانات
لقد قمت بإنشاء منشور يوضح كيفية استخدام JWTs أو استراتيجيات جلسات قاعدة البيانات مع NextAuth. انقر هنا