অ্যাপ্লিকেশন ডেভেলপমেন্টে Session Token — এটি কী, কাজের নীতি এবং JWT থেকে পার্থক্য

Session Token কী?

Session Token (সেশন শনাক্তকারী) হল একটি অনন্য স্ট্রিং যা সার্ভার ব্যবহারকারীর প্রমাণীকরণের পরে তৈরি করে এবং সেশন ডেটার সাথে যুক্ত করে। টোকেনে ব্যবহারকারীর কোনো তথ্য থাকে না — এটি কেবল সার্ভারে সংরক্ষিত ডেটার একটি চাবি। এই পদ্ধতিকে stateful প্রমাণীকরণ বলা হয়: সার্ভার প্রতিটি সক্রিয় সেশনের অবস্থা সংরক্ষণ করে এবং প্রতিটি অনুরোধে এটি যাচাই করে।

সেশন ডেটার মধ্যে অন্তর্ভুক্ত: ব্যবহারকারী আইডি, লগইন সময়, 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 ফেরত দিতে অনুমতি দেয়।