ایپلیکیشن ڈویلپمنٹ میں Session Token — یہ کیا ہے، کام کرنے کا اصول اور JWT سے فرق

Session Token کیا ہے؟

Session Token (سیشن شناخت کنندہ) ایک منفرد سٹرنگ ہے جو سرور صارف کی تصدیق کے بعد بناتا ہے اور سیشن ڈیٹا سے منسلک کرتا ہے۔ ٹوکن میں صارف کی کوئی معلومات نہیں ہوتی — یہ صرف سرور پر محفوظ ڈیٹا کی ایک کنجی ہے۔ اس طریقہ کار کو stateful تصدیق کہا جاتا ہے: سرور ہر فعال سیشن کی حالت محفوظ کرتا ہے اور ہر درخواست پر اسے جانچتا ہے۔

سیشن ڈیٹا میں شامل ہیں: صارف کی ID، لاگ ان کا وقت، IP پتہ، user-agent، اجازتوں کی فہرست، آخری سرگرمی کا وقت۔ جب کلائنٹ 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 کوکی کے ذریعے یا Authorization HTTP ہیڈر کے ذریعے۔ کوکی ویب ایپلیکیشنز کے لیے روایتی طریقہ ہے: سرور HttpOnly (JavaScript سے ناقابل رسائی)، Secure (صرف HTTPS)، اور SameSite (CSRF تحفظ) فلیگز کے ساتھ کوکی سیٹ کرتا ہے۔ موبائل ایپلیکیشنز کے لیے، Authorization: Bearer <session_token> ہیڈر زیادہ عام طور پر استعمال ہوتا ہے، کیونکہ مقامی کلائنٹس میں کوکی کا طریقہ کار ہمیشہ آسان نہیں ہوتا۔

Session Token کی زندگی کا چکر

Session Token کی زندگی کا چکر تین مراحل پر مشتمل ہے: تخلیق، فعال سیشن کی بحالی، اور ختم کرنا۔ ہر مرحلے میں ٹوکن کے رساو یا روک تھام کے لیے مناسب حفاظتی ترتیب کی ضرورت ہوتی ہے۔

تخلیق، ذخیرہ اور حذف کرنا

تخلیق — سرور 128–256 بٹ کی خفیہ نگاری کے لحاظ سے محفوظ بے ترتیب سٹرنگ بناتا ہے (مثال کے طور پر، Java میں SecureRandom یا Python میں os.urandom کے ذریعے)۔ ٹوکن ناقابل پیشن گوئی ہونا چاہیے — اینٹروپی کے بغیر UUID یا ٹائم اسٹیمپ کا استعمال ناقابل قبول ہے۔ کلائنٹ پر ذخیرہ: iOS میں — Keychain، Android میں — EncryptedSharedPreferences، ویب میں — HttpOnly کوکی۔ حذف کرنا لاگ آؤٹ پر ہوتا ہے: کلائنٹ ذخیرہ سے ٹوکن ہٹاتا ہے، سرور Redis سے سیشن ریکارڈ حذف کرتا ہے۔ لاگ آؤٹ کے بعد، session_token بیکار ہو جاتا ہے — سرور کو متعلقہ ریکارڈ نہیں ملے گا۔

SANS Institute، 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 کمانڈ) کا استعمال پس منظر کے کاموں پر بوجھ کے بغیر میعاد ختم شدہ سیشنز کو خود بخود صاف کرتا ہے۔ 1 گھنٹے کے TTL اور 10,000 بیک وقت صارفین کے بوجھ والے سیشنز کے لیے، Redis 1 KB سیشن سائز پر تقریباً 1 GB RAM استعمال کرتا ہے، جو اسے زیادہ تر ایپلیکیشنز کے لیے لاگت مؤثر بناتا ہے۔

Session Token کی حفاظت

Session Token کی حفاظت دو اصولوں پر مبنی ہے: ٹوکن ناقابل پیشن گوئی ہونا چاہیے اور منتقلی اور ذخیرہ کے دوران محفوظ ہونا چاہیے۔ اہم خطرات ٹوکن کی روک تھام (man-in-the-middle, XSS)، اس کی پیشن گوئی (کمزور تخلیق)، اور سیشن فکسیشن (session fixation) ہیں۔

ٹوکن چوری سے تحفظ

تحفظ میں شامل ہے: ٹوکن والی تمام درخواستوں کے لیے HTTPS کا استعمال، مختصر سیشن TTL (15–60 منٹ غیرفعالیت) سیٹ کرنا، سیشن کو IP اور user-agent سے باندھنا (ہر درخواست پر اضافی تصدیق)، کوکیز کے لیے Secure اور HttpOnly فلیگز کا استعمال، اور حساس کارروائیوں (پاس ورڈ تبدیل کرنا، مراعات بڑھانا) کے بعد باقاعدہ session token گردش۔ OWASP لاگ ان کے بعد نیا سیشن بناتے وقت پرانے سیشن کو باطل کرنے کے ساتھ سیشن مینجمنٹ لاگو کرنے کی بھی سفارش کرتا ہے — یہ session fixation کو روکتا ہے۔

OWASP ASVS، 2025 کے مطابق، ایک سیشن کم از کم دو عوامل سے بندھا ہونا چاہیے: خود ٹوکن (جو کلائنٹ کے پاس ہے) اور IP/user-agent (جو سرور جانتا ہے)۔ اگر یہ عوامل مماثل نہ ہوں تو سرور کو سیشن ختم کرنا چاہیے اور دوبارہ تصدیق کی ضرورت ہونی چاہیے۔

Kotlin میں نفاذ کی مثال

ذیل میں Spring Boot اور Redis کا استعمال کرتے ہوئے Kotlin میں سرور سائڈ session token کے نفاذ کی مثال دی گئی ہے۔ سرور SecureRandom کے ذریعے خفیہ نگاری کے لحاظ سے محفوظ ٹوکن بناتا ہے، TTL کے ساتھ Redis میں سیشن محفوظ کرتا ہے اور ہر درخواست پر اسے جانچتا ہے۔ کوڈ تین اہم کارروائیوں کو ظاہر کرتا ہے: سیشن بنانا، درست کرنا اور باطل کرنا۔

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)
    }
}

یہ نفاذ Redis سے تھریڈ محفوظ کنکشن کے لیے JedisPool استعمال کرتا ہے۔ createSession طریقہ 1 گھنٹے (3600 سیکنڈ) کا TTL سیٹ کرتا ہے — اس مدت کے بعد Redis خود بخود ریکارڈ حذف کر دے گا۔ validateSession طریقہ غیر موجود یا میعاد ختم شدہ سیشنز کے لیے null لوٹاتا ہے، جس سے سرور غلط ٹوکن والی درخواست کو صحیح طریقے سے سنبھال سکتا ہے اور HTTP 401 لوٹا سکتا ہے۔