Session Token في تطوير التطبيقات — ما هو، مبدأ العمل والاختلافات عن JWT

ما هو Session Token؟

Session Token (معرف الجلسة) هو سلسلة فريدة يولدها الخادم ويربطها ببيانات الجلسة بعد مصادقة المستخدم. الرمز لا يحتوي على أي معلومات عن المستخدم — إنه مجرد مفتاح للبيانات المخزنة على الخادم. يُسمى هذا النهج المصادقة بحالة الجلسة (stateful authentication): الخادم يخزن حالة كل جلسة نشطة ويتحقق منها عند كل طلب.

تشمل بيانات الجلسة: معرف المستخدم، وقت تسجيل الدخول، عنوان IP، وكيل المستخدم، قائمة الأذونات، وقت آخر نشاط. عندما يرسل العميل طلباً مع session token، يبحث الخادم عن السجل المقابل في مخزن الجلسات، ويتحقق من صحته، ويسترد البيانات لمعالجة الطلب. إذا كان سجل الجلسة مفقوداً أو منتهي الصلاحية، يُرجع الخادم خطأ في المصادقة ويطلب إعادة تسجيل الدخول.

وفقاً لـ OWASP، 2025، يبقى session token المعيار للتطبيقات التي تتطلب إبطالاً فورياً للوصول — على سبيل المثال، في الأنظمة المصرفية والبوابات المؤسسية حيث يجب أن يكون المسؤول قادراً على إنهاء جلسة المستخدم فوراً. في هذه الأنظمة، يوفر session token تحكماً كاملاً في الوصول لا يمكن تحقيقه للرموز عديمة الحالة (stateless) بدون آليات حظر إضافية.

كيف يعمل Session Token

تبدأ العملية عندما يرسل العميل بيانات الاعتماد إلى خادم المصادقة. يتحقق الخادم من اسم المستخدم وكلمة المرور، وينشئ سجل جلسة في المخزن (عادة Redis أو قاعدة بيانات)، ويعيد session token فريداً إلى العميل. يحفظ العميل الرمز ويرسله مع كل طلب لاحق، ويتحقق الخادم من وجود الجلسة وصلاحيتها في كل مرة.

جلسة الخادم والتخزين

Redis هو مخزن الجلسات الأكثر شهرة بفضل التخزين في الذاكرة ودعم TTL (مدة الصلاحية). تُخزَّن كل جلسة كزوج مفتاح-قيمة، حيث المفتاح هو session token والقيمة هي كائن JSON يحتوي على بيانات الجلسة. يقوم TTL تلقائياً بحذف الجلسات منتهية الصلاحية. البدائل: Memcached (ذاكرة فقط، بدون حفظ على القرص)، PostgreSQL/MySQL (دائمة لكن أبطأ)، و DynamoDB (للبنية التحتية لـ AWS).

مثال على بنية الجلسة في Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. يقوم الخادم بتحديث lastAccess عند كل طلب، مما يسمح بتطبيق مهلة عدم النشاط — إنهاء تلقائي للجلسة بعد فترة من الخمول.

الكوكيز مقابل العنوان

Session Token يمكن نقله بطريقتين: عبر كوكيز HTTP أو عبر عنوان HTTP Authorization. الكوكيز هي الطريقة التقليدية لتطبيقات الويب: يحدد الخادم كوكيز مع علامات HttpOnly (غير قابلة للوصول من JavaScript)، Secure (HTTPS فقط)، و SameSite (حماية من CSRF). للتطبيقات المحمولة، يُستخدم عنوان Authorization: Bearer <session_token> بشكل أكثر شيوعاً، لأن آلية الكوكيز ليست مريحة دائماً في العملاء الأصليين.

دورة حياة Session Token

دورة حياة session token تشمل ثلاث مراحل: الإنشاء، الحفاظ على الجلسة النشطة، والإنهاء. تتطلب كل مرحلة تكوين أمني مناسب لمنع تسرب الرمز أو اعتراضه.

الإنشاء والتخزين والحذف

الإنشاء — يولد الخادم سلسلة عشوائية آمنة تشفيرياً بطول 128–256 بت (على سبيل المثال، عبر SecureRandom في Java أو os.urandom في Python). يجب أن يكون الرمز غير قابل للتنبؤ — استخدام UUID أو الطابع الزمني بدون إنتروبيا غير مقبول. التخزين على العميل: في iOS — Keychain، في Android — EncryptedSharedPreferences، في الويب — كوكيز HttpOnly. الحذف يحدث عند تسجيل الخروج: يحذف العميل الرمز من المخزن، ويحذف الخادم سجل الجلسة من Redis. بعد تسجيل الخروج، يصبح session token عديم الفائدة — لن يجد الخادم سجلاً مقابلاً.

وفقاً لمعهد SANS، 2025، التنفيذ الصحيح لإنهاء الجلسة (تسجيل الخروج مع التنظيف على الخادم) يمنع ما يصل إلى 70% من الهجمات باستخدام الرموز المسروقة. من المهم جداً ليس فقط حذف الرمز على العميل، ولكن أيضاً إبطال الجلسة على الخادم.

Session Token مقابل JWT

Session Token و JWT يمثلان نهجين مختلفين للمصادقة. Session Token بحالة جلسة (stateful — الخادم يخزن الحالة)، JWT عديم الحالة (stateless — البيانات داخل الرمز). يعتمد الاختيار بينهما على بنية التطبيق ومتطلبات الأمان.

متى تختار Session Token

Session Token يفضل عندما: يكون الإبطال الفوري للجلسات مطلوباً (الخدمات المصرفية، لوحات الإدارة)، يعمل التطبيق على خادم واحد أو عدة خوادم مع Redis مشترك، بيانات الجلسة كبيرة ولا تناسب JWT، أو عندما يريد الفريق تقليل خطر تسرب البيانات عبر فك ترميز الرمز. في هذه السيناريوهات، يوفر session token حظراً فورياً للوصول عند النشاط المشبوه — يكفي حذف سجل واحد من Redis لتصبح جميع جلسات المستخدم غير صالحة.

وفقاً لـ Redis، 2025، استخدام TTL على مستوى مفاتيح الجلسة (أمر EXPIRE) ينظف تلقائياً الجلسات منتهية الصلاحية دون أعباء إضافية على المهام الخلفية. للجلسات ذات TTL لمدة ساعة واحدة وحمل 10,000 مستخدم متزامن، يستهلك Redis حوالي 1 جيجابايت من الذاكرة العشوائية بحجم جلسة 1 كيلوبايت، مما يجعله فعالاً من حيث التكلفة لمعظم التطبيقات.

أمان Session Token

يعتمد أمان session token على مبدأين: يجب أن يكون الرمز غير قابل للتنبؤ ومحمياً أثناء النقل والتخزين. التهديدات الرئيسية هي اعتراض الرمز (man-in-the-middle، XSS)، التنبؤ به (توليد ضعيف)، وتثبيت الجلسة (session fixation).

الحماية من سرقة الرمز

تشمل الحماية: استخدام HTTPS لجميع الطلبات التي تحمل الرمز، تعيين TTL قصير للجلسة (15–60 دقيقة من عدم النشاط)، ربط الجلسة بعنوان IP ووكيل المستخدم (تحقق إضافي عند كل طلب)، استخدام علامات Secure و HttpOnly للكوكيز، وتدوير session token بشكل دوري بعد العمليات الحساسة (تغيير كلمة المرور، رفع الصلاحيات). يوصي OWASP أيضاً بتنفيذ إدارة الجلسات مع إبطال الجلسة القديمة عند إنشاء جلسة جديدة بعد تسجيل الدخول — وهذا يمنع تثبيت الجلسة.

وفقاً لـ OWASP ASVS، 2025، يجب ربط الجلسة بعاملين على الأقل: الرمز نفسه (ما يملكه العميل) وعنوان IP/وكيل المستخدم (ما يعرفه الخادم). إذا لم تتطابق هذه العوامل، يجب على الخادم إنهاء الجلسة وطلب إعادة المصادقة.

مثال تنفيذ في Kotlin

فيما يلي مثال على تنفيذ session token من جانب الخادم باستخدام Kotlin مع Spring Boot و Redis. يولد الخادم رمزاً آمناً تشفيرياً عبر SecureRandom، ويحفظ الجلسة في Redis مع TTL، ويتحقق منها عند كل طلب. يوضح الكود ثلاث عمليات رئيسية: إنشاء الجلسة، والتحقق من صحتها، وإبطالها.

data class Session(
    val userId: Long,
    val role: String,
    val createdAt: Long,
    val lastAccess: Long
)

object SessionManager {
    private val redis = JedisPool("localhost", 6379)

    fun createSession(userId: Long, role: String): String {
        val token = generateSecureToken()
        val session = Session(userId, role, now(), now())
        redis.resource.use { conn ->
            conn.setex("session:$token", 3600, toJson(session))
        }
        return token
    }

    fun validateSession(token: String): Session? {
        redis.resource.use { conn ->
            val json = conn.get("session:$token") ?: return null
            return fromJson(json)
        }
    }

    fun invalidateSession(token: String) {
        redis.resource.use { it.del("session:$token") }
    }

    private fun generateSecureToken(): String {
        val bytes = ByteArray(32)
        SecureRandom().nextBytes(bytes)
        return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)
    }
}

يستخدم هذا التنفيذ JedisPool للاتصال الآمن للخيوط بـ Redis. يحدد أسلوب createSession TTL لمدة ساعة واحدة (3600 ثانية) — بعد هذه المدة، سيحذف Redis السجل تلقائياً. يُرجع أسلوب validateSession قيمة null للجلسات غير الموجودة أو منتهية الصلاحية، مما يسمح للخادم بمعالجة الطلب برمز غير صالح بشكل صحيح وإرجاع HTTP 401.