الفارق الذي لا تراه في أول 6 أشهر
قبل سنتين، جاءني مؤسس ستارتاب كويتي بمشكلة: نظامهم كان يعمل بـ JWT، وفجأة اكتشفوا أنهم لا يستطيعون إنهاء دخول المستخدم فوراً. عندما يغير المستخدم كلمة السر، الـ JWT القديم يبقى صحيحاً لمدة 24 ساعة كاملة. جربوا حذفه من قاعدة البيانات — لكن JWT لا يتحقق من قاعدة البيانات، يتحقق من التوقيع فقط. النتيجة: مستخدم واحد مع أجهزة متعددة، وأحد الأجهزة مخترق، وأنت عاجز عن إيقاف الوصول فوراً. هذا الفارق وحده يكلف آلاف الدنانير في ساعات عمل الهندسة والقانونية.
لم أتفاجأ. لقد رأيت هذا الخطأ نفسه 7 مرات على الأقل في الكويت والخليج. كل مرة، الشركة اختارت JWT لأنها 'حديثة' أو 'بدون خادم'، وكل مرة، اصطدموا بالواقع الأمني.
JWT: سريع وموثوق، لكن بشرط واحد أساسي تفشل به معظم الشركات
فهم JWT سهل: أنت توقّع رمزاً يحتوي على بيانات المستخدم، والعميل يرسله معه في كل طلب، والخادم يتحقق من التوقيع دون الحاجة لقاعدة بيانات. هذا يعني سرعة عالية وقابلية توسع ممتازة — لا داعي لجدول جلسات في قاعدة البيانات.
المشكلة الأولى: الرمز لا يُنهى إلا عند انتهاء صلاحيته. إذا حددت صلاحية 24 ساعة، فأنت عالق بـ 24 ساعة. تريد إنهاء الوصول فوراً؟ الحل الوحيد هو قائمة سوداء (blacklist) — وهنا يأتي السخف: أنت الآن تحتفظ بجدول في قاعدة البيانات بنفس الطريقة تماماً كما لو اخترت الجلسات من البداية. الفرق أنك الآن تتحقق من الجدول على كل طلب، بدلاً من قراءة سجل محدد.
المشكلة الثانية: البيانات المضمنة في JWT تصبح قديمة. إذا غيّر المستخدم صلاحياته (أصبح مديراً، على سبيل المثال)، JWT القديم يحتفظ بالدور القديم. مرة أخرى: قائمة سوداء أو تحقق من قاعدة البيانات.
في الممارسة العملية، معظم الأنظمة الناشئة تتجاهل هاتين المشكلتين لأول 6 أشهر. بعدها، أو عند حدث أمني، تضطر إلى إعادة البناء. من تجربتي: تكلفة هذا الخطأ تتراوح بين 500 و2000 دينار كويتي في ساعات الهندسة.
متى تختار JWT؟
اختر JWT عندما: (1) صلاحيتك قصيرة جداً (15 دقيقة أو أقل)، و(2) تقبل تأخير من دقائق قليلة في إنهاء الوصول، و(3) لا تتوقع تغييرات متكررة في دور المستخدم أو الصلاحيات. بصراحة، معظم الشركات الناشئة لا تحتاج إلى JWT. لا.
الجلسات: 'قديمة'، نعم — لكن بصفة غير مؤذية
الجلسات تعني أن الخادم يحفظ معرّف فريد لكل مستخدم مسجل دخول. العميل يرسل هذا المعرّف، والخادم يتحقق من جدول الجلسات في الذاكرة أو قاعدة البيانات. نعم، هذا يتطلب جدول، وهذا يتطلب قراءة قاعدة بيانات على كل طلب.
الفائدة: تحكم كامل وفوري. أردت إنهاء جلسة؟ احذفها من الجدول. انتهى. المستخدم محظور في الحال التالي. غيّر صلاحيات المستخدم؟ الجلسة التالية تقرأ البيانات الحديثة مباشرة.
التكلفة: قراءة إضافية على قاعدة البيانات. في نظام صغير (10,000 مستخدم نشط)، هذا لا يلاحظ. في نظام ضخم (مليون مستخدم نشط متزامن)، هذا يمكن أن يصبح عنق زجاجة.
الآن، هل الجلسات 'قديمة'؟ تقنياً نعم. عملياً؟ لا. معظم الخدمات على الويب الحديثة — بما فيها أكبر الشركات — لا تزال تستخدم الجلسات أو شيء مشابه جداً. AWS، Google، Meta — كلهم يحفظون حالة جلسة بشكل ما.
متى تختار الجلسات؟
اختر الجلسات عندما تريد: (1) تحكم فوري في الوصول، (2) بيانات صلاحيات حية (ليست مجمدة في رمز)، و(3) سهولة تشغيلية. إذا كنت تبني نظاماً يخدم شركة متوسطة الحجم أو حتى كبيرة، الجلسات غالباً ما تكون الخيار الأذكى — ليس الأضعف.
OAuth2: إيقاف. هذا ليس منافس.
أكبر التباس أراه في الكويت والخليج هو مساواة OAuth2 بـ JWT والجلسات. هذا خطأ أساسي. OAuth2 ليس آلية مصادقة، هو معيار تفويض. الفرق؟ المصادقة تجيب عن: 'من أنت؟'. التفويض تجيب عن: 'ماذا يمكنك أن تفعل؟'.
OAuth2 يقول: 'أنت تريد من تطبيقي أن ينقل أموالك من حسابك البنكي. أنا لا أخزن كلمة سرك، بدلاً من ذلك أطلب من البنك مباشرة أن يعطيك رمز خاص ليقول للبنك: هذا التطبيق له الإذن بفعل X'.
هذا مفيد جداً عندما تريد تطبيقاً ثالثاً (مثل تطبيق محاسبة) أن يقرأ بيانات من خدمة أخرى (مثل بنك). لكنه ليس بديلاً عن JWT أو الجلسات — هو طبقة إضافية فوقها.
في الواقع، معظم التطبيقات التي تستخدم 'تسجيل الدخول عبر Google' تستخدم OAuth2 للتفويض، ثم تنشئ جلسة أو JWT خاصة بهم بعد ذلك.
الجدول الذي لم يشرحه أحد بوضوح
| المعيار | JWT | الجلسات | OAuth2 |
|---|---|---|---|
| المصادقة (من أنت؟) | ✓ نعم | ✓ نعم | ✗ لا (التفويض فقط) |
| إنهاء فوري | ✗ يحتاج قائمة سوداء | ✓ حذف فقط | — |
| بيانات حية | ✗ مجمدة حتى انتهاء الصلاحية | ✓ حية دائماً | — |
| قابلية التوسع (نطاق كبير) | ✓ سريع جداً | △ يحتاج تخزين موزع | — |
| التعقيد التشغيلي | △ متوسط | △ متوسط | ✓ مدار من طرف ثالث |
| الأمان الافتراضي | △ جيد إذا طُبق بشكل صحيح | ✓ آمن بشكل أساسي | ✓ آمن (طرف ثالث موثوق) |
الملاحظة الأساسية
اختيارك لا يعتمد على أي واحد 'حديث' أو 'قديم'، يعتمد على سؤال واحد: هل تحتاج تحكماً فورياً في الوصول وبيانات حية، أم أن سرعة عالية وتوسع بلا حدود أهم؟ إذا كان الجواب الأول، اختر الجلسات. إذا كان الثاني، JWT — لكن ببقائمة سوداء.
من الخبرة: الأخطاء الأربعة التي رأيتها مئات المرات
الخطأ الأول: اختيار JWT لأن المطور الأول 'أحب الفكرة'. النتيجة: بعد سنة، النظام في إنتاج، والشركة تكتشف المشكلة الأمنية. الحل الآن يكلف 10 أضعاف ما كان سيكلف في البداية.
الخطأ الثاني: استخدام OAuth2 بدلاً من JWT أو الجلسات، لأنه 'الخيار الأمني'. OAuth2 لا يحل مشكلة المصادقة الأساسية — هو إضافة معقدة لحل لم تكن تحتاجها.
الخطأ الثالث: حفظ JWT في Local Storage وتوقع أنه آمن. Local Storage عرضة لـ XSS. إذا كان نظامك عرضة لـ XSS، JWT في Local Storage مثل حفظ كلمة السر في نص عادي.
الخطأ الرابع: استخدام الجلسات بدون HTTPS. ملفات تعريف الارتباط (Cookies) بدون الإشارة Secure متعرضة للاختراق. في الواقع، إذا كان موقعك بدون HTTPS الآن، توقف عن القراءة واحصل على شهادة SSL. الآن.
الخيار الهجين: الأفضل من كليهما
الخيار الذي أوصي به لمعظم الشركات الناشئة الخليجية هو خيار هجين:
استخدم جلسات قصيرة الأجل + رموز تحديث طويلة الأجل.
كيفية العمل: عند تسجيل الدخول، أصدر جلسة قصيرة (15 دقيقة) وجواز تحديث طويل (30 يوماً). العميل يستخدم الجلسة في الطلبات اليومية. عندما تنتهي الجلسة، يستخدم جواز التحديث للحصول على جلسة جديدة دون إعادة إدخال كلمة السر. إذا حاول جواز التحديث بعد إنهاء الوصول، يُرفع. هذا يعطيك:
- سرعة عالية (الجلسات القصيرة سهلة التخزين المؤقت)
- تحكم فوري (جلسات قصيرة = نقطة تحكم متكررة)
- أمان محسّن (حتى لو سُرقت الجلسة، صلاحيتها 15 دقيقة فقط)
- تجربة مستخدم جيدة (تحديث بدون إزعاج)
هذا الخيار الهجين هو ما استخدمه في آخر 5 مشاريع ناشئة في الكويت والإمارات، وكل واحد منها كان راضياً عنه.
النصيحة الأخيرة
أول سؤال أطرحه على عميل يسأل عن المصادقة هو: 'كم مستخدم نشط متزامن تتوقع في السنة الأولى؟'. بناءً على الرقم، الخيار يصبح واضحاً. إذا كان أقل من 50,000، الجلسات أو الهجين كافٍ. إذا كان أكثر من مليون، JWT يصبح ضرورياً — لكن بقائمة سوداء وبيانات حية. إذا لم تعرف الرقم، اختر الهجين — لا تتبع الموضة.