Session Token در توسعه برنامه‌ها — چیست، اصل کار و تفاوت‌ها با JWT

Session Token چیست؟

Session Token (شناسه جلسه) — این یک رشته یکتاست که سرور تولید کرده و پس از احراز هویت کاربر به داده‌های جلسه متصل می‌کند. توکن هیچ اطلاعاتی درباره کاربر ندارد — این فقط کلید داده‌های ذخیره شده روی سرور است. این رویکرد احراز هویت stateful نامیده می‌شود: سرور وضعیت هر جلسه فعال را ذخیره کرده و در هر درخواست آن را بررسی می‌کند.

داده‌های جلسه شامل: شناسه کاربر، زمان ورود، آدرس IP، user-agent، فهرست مجوزها (permissions)، زمان آخرین فعالیت است. وقتی کلient درخواستی با session token ارسال می‌کند، سرور رکورد مربوطه را در مخزن جلسات پیدا می‌کند، اعتبار آن را بررسی کرده و داده‌ها را برای پردازش درخواست استخراج می‌کند. اگر رکورد جلسه وجود نداشته باشد یا منقضی شده باشد، سرور خطای احراز هویت بازگردانده و نیاز به ورود مجدد دارد.

بر اساس داده‌های OWASP، 2025، session token استانداردی برای برنامه‌هایی است که نیاز به باطل‌سازی فوری دسترسی دارند — به عنوان مثال، در سیستم‌های بانکی و پورتال‌های سازمانی، جایی که مدیر باید بتواند جلسه کاربر را فوراً پایان دهد. در چنین سیستم‌هایی session token کنترل کامل دسترسی را فراهم می‌کند که برای توکن‌های stateless بدون مکانیزم‌های اضافی مسدودسازی دست‌نیافتنی است.

Session Token چگونه کار می‌کند

فرآیند کار با ارسال اطلاعات احراز هویت توسط کلient به سرور شروع می‌شود. سرور نام کاربری و رمز عبور را بررسی می‌کند، یک رکورد جلسه در مخزن (معمولاً Redis یا پایگاه داده) ایجاد کرده و یک session token یکتا به کلient بازمی‌گرداند. کلient توکن را ذخیره کرده و با هر درخواست بعدی ارسال می‌کند و سرور هر بار وجود و اعتبار جلسه را بررسی می‌کند.

جلسه سرور و مخزن

Redis — محبوب‌ترین مخزن جلسات به دلیل ذخیره‌سازی درون حافظه و پشتیبانی TTL (زمان حیات). هر جلسه به صورت کلید-مقدار ذخیره می‌شود که کلید session token و مقدار یک شی JSON با داده‌های جلسه است. TTL به طور خودکار جلسات منقضی شده را حذف می‌کند. جایگزین‌ها: Memcached (فقط حافظه، بدون ذخیره روی دیسک)، PostgreSQL/MySQL (ماندگاری، اما کندتر) و DynamoDB (برای زیرساخت AWS).

مثال ساختار جلسه در Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. سرور lastAccess را در هر درخواست به‌روزرسانی می‌کند که امکان پیاده‌سازی مهلت عدم فعالیت را فراهم می‌کند — پایان خودکار جلسه پس از دوره بی‌تحرکی.

Cookie در مقابل Header

Session Token می‌تواند به دو روش منتقل شود: از طریق HTTP cookie یا از طریق هدر HTTP Authorization. Cookie — روش سنتی برای برنامه‌های وب: سرور cookie را با پرچم‌های HttpOnly (غیرقابل دسترس برای JavaScript)، Secure (فقط HTTPS) و SameSite (محافظت در برابر CSRF) تنظیم می‌کند. برای برنامه‌های موبایل بیشتر از هدر Authorization: Bearer <session_token> استفاده می‌شود زیرا مکانیزم cookie همیشه در کلientهای بومی راحت نیست.

چرخه حیات Session Token

چرخه حیات session token شامل سه مرحله است: ایجاد، نگهداری جلسه فعال و پایان. هر مرحله نیاز به پیکربندی امنیتی صحیح برای جلوگیری از نشت یا رهگیری توکن دارد.

ایجاد، ذخیره و حذف

ایجاد — سرور یک رشته تصادفی رمزنگاری شده به طول 128–256 بیت تولید می‌کند (مثلاً از طریق SecureRandom در Java یا os.urandom در Python). توکن باید غیرقابل پیش‌بینی باشد — استفاده از UUID یا timestamp بدون آنتروپی مجاز نیست. ذخیره در کلient: در iOS — Keychain، در Android — EncryptedSharedPreferences، در وب — HttpOnly cookie. حذف هنگام خروج انجام می‌شود: کلient توکن را از مخزن حذف می‌کند، سرور رکورد جلسه را از Redis حذف می‌کند. پس از خروج session token بی‌استفاده می‌شود — سرور رکورد مربوطه را پیدا نخواهد کرد.

بر اساس داده‌های SANS Institute، 2025، پیاده‌سازی صحیح پایان جلسه (خروج با پاکسازی روی سرور) از 70٪ حملات با استفاده از توکن‌های دزدیده شده جلوگیری می‌کند. این که نه تنها توکن را در کلient حذف کنیم بلکه جلسه را در سرور نیز باطل کنیم بسیار مهم است.

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 1 ساعت و بار 10 000 کاربر همزمان با اندازه جلسه 1 KB، Redis حدود 1 GB RAM مصرف می‌کند که آن را برای اکثر برنامه‌ها مقرون به صرفه می‌کند.

امنیت Session Token

امنیت session token بر دو اصل استوار است: توکن باید غیرقابل پیش‌بینی و در هنگام انتقال و ذخیره محافظت شده باشد. تهدیدات اصلی — رهگیری توکن (man-in-the-middle، XSS)، پیش‌بینی آن (تولید ضعیف) و تثبیت جلسه (session fixation).

محافظت در برابر سرقت توکن

محافظت شامل: استفاده از HTTPS برای تمام درخواست‌های دارای توکن، تنظیم TTL کوتاه جلسه (15–60 دقیقه عدم فعالیت)، اتصال جلسه به IP و user-agent (بررسی اضافی در هر درخواست)، استفاده از پرچم‌های Secure و HttpOnly برای cookie، چرخش منظم session token پس از عملیات حساس (تغییر رمز عبور، ارتقاء مجوزها). OWASP همچنین توصیه می‌کند مدیریت جلسه را با باطل‌سازی جلسه قدیمی هنگام ایجاد جلسه جدید پس از ورود پیاده‌سازی کنید — این از تثبیت جلسه جلوگیری می‌کند.

بر اساس داده‌های OWASP ASVS، 2025، جلسه باید حداقل به دو عامل متصل باشد: خود توکن (آنچه کلient دارد) و IP/user-agent (آنچه سرور می‌داند). در صورت عدم تطابق این عوامل، سرور باید جلسه را پایان داده و احراز هویت مجدد را بخواهد.

مثال پیاده‌سازی در 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 برای اتصال thread-safe به Redis استفاده می‌کند. متد createSession TTL را 1 ساعت (3600 ثانیه) تنظیم می‌کند — پس از این مدت Redis به طور خودکار رکورد را حذف می‌کند. متد validateSession برای جلسات وجود نداشته یا منقضی شده null بازمی‌گرداند که به سرور اجازه می‌دهد درخواست با توکن نامعتبر را به درستی پردازش کرده و HTTP 401 بازگرداند.