Sessions أم Tokens لتسجيل الدخول؟ مقارنة معمارية قبل اختيار JWT

اختيار Sessions أو Tokens ليس مسابقة بين قديم وحديث. كلاهما طريقة لحمل حالة المصادقة بين الطلبات، لكن مكان حفظ الحالة وكيفية الإبطال وال ـclients المستهدفة يختلف. تطبيق ويب تقليدي قد يكون أبسط وأأمن باستخدام Session cookie HttpOnly، بينما API تخدم تطبيقات متعددة قد تستفيد من Access tokens قصيرة العمر. المشكلة تبدأ عندما تُختار JWT لمجرد تجنب Session store بدون حساب تكلفة revocation وإدارة refresh tokens.

Server-side Session تجعل الإبطال مركزيًا

المتصفح يحمل Session ID عشوائية في Cookie، والخادم يخزن الحالة المرتبطة بها. عند logout أو تعطيل الحساب تستطيع حذف session فورًا. المقابل هو الحاجة إلى shared session store أو sticky architecture عند التوسع.

Access Token تنقل بعض الحالة إلى credential

Access token قد تكون opaque أو JWT. Resource server تتحقق منها وتطبق scopes/audience. JWT stateless تقلل lookup في بعض التصاميم، لكن token المسروقة تظل صالحة حتى expiry ما لم تضف revocation أو تحققًا إضافيًا.

Refresh Token هي الجزء الأكثر حساسية

لتجنب Access token طويلة العمر، يستخدم النظام Refresh token لإصدار Access جديدة. يجب حمايتها وتدويرها وإبطالها عند logout أو compromise. وضع Refresh token طويلة العمر في LocalStorage يوسع أثر XSS.

Browser app لا تحتاج JWT دائمًا

إذا Frontend و Backend تحت نفس origin أو نفس التطبيق، Session cookie قد تكون أبسط وتمنع تعقيد تخزين tokens في JavaScript. JWT مفيدة عندما تحتاج claims موزعة أو APIs متعددة، لكن لا تجعلها هدفًا بذاتها.

CSRF و XSS تختلف حسب التخزين

Cookie تُرسل تلقائيًا، لذلك تحتاج SameSite و CSRF defenses في الحالات المناسبة. Token تُضاف يدويًا غالبًا، ما يقلل بعض CSRF لكنه قد يعرضها أكثر ل ـXSS إذا خُزنت بطريقة يستطيع JS الوصول إليها. لا يوجد خيار يلغي بقية الدفاعات.

اختر على أساس المتطلبات

اسأل: هل نحتاج revoke فوري؟ كم client؟ هل هناك mobile/native؟ هل APIs مستقلة؟ هل نحتاج SSO/OIDC؟ ما العمر المقبول للاعتماد؟ ثم اختر النموذج الأقل تعقيدًا الذي يحقق المطلوب.