Session Token dalam pengembangan aplikasi — apa itu, prinsip kerja, dan perbedaan dengan JWT

Apa itu Session Token?

Session Token (pengidentifikasi sesi) — adalah string unik yang dihasilkan server dan dikaitkan dengan data sesi setelah autentikasi pengguna. Token tidak berisi informasi apa pun tentang pengguna — ini hanyalah kunci untuk data yang disimpan di server. Pendekatan ini disebut autentikasi stateful: server menyimpan status setiap sesi aktif dan memeriksanya pada setiap permintaan.

Data sesi meliputi: pengidentifikasi pengguna, waktu masuk, alamat IP, user-agent, daftar izin (permissions), waktu aktivitas terakhir. Ketika klien mengirim permintaan dengan session token, server menemukan catatan yang sesuai di penyimpanan sesi, memeriksa validitasnya, dan mengambil data untuk memproses permintaan. Jika catatan sesi tidak ada atau kedaluwarsa, server mengembalikan kesalahan autentikasi dan meminta login ulang.

Menurut data OWASP, 2025, session token tetap menjadi standar untuk aplikasi yang memerlukan pencabutan akses segera — misalnya, dalam sistem perbankan dan portal perusahaan, di mana administrator harus dapat mengakhiri sesi pengguna secara instan. Dalam sistem seperti itu, session token memberikan kontrol penuh atas akses, yang tidak dapat dicapai oleh token stateless tanpa mekanisme pemblokiran tambahan.

Bagaimana Session Token Bekerja

Proses kerja dimulai ketika klien mengirim kredensial ke server autentikasi. Server memeriksa login dan kata sandi, membuat catatan sesi di penyimpanan (biasanya Redis atau basis data) dan mengembalikan session token unik ke klien. Klien menyimpan token dan mengirimkannya dengan setiap permintaan berikutnya, dan server setiap kali memeriksa keberadaan dan validitas sesi.

Sesi server dan penyimpanan

Redis — penyimpanan sesi paling populer berkat penyimpanan in-memory dan dukungan TTL (time-to-live). Setiap sesi disimpan sebagai pasangan kunci-nilai, di mana kuncinya adalah session token dan nilainya adalah objek JSON dengan data sesi. TTL secara otomatis menghapus sesi yang kedaluwarsa. Alternatif: Memcached (hanya memori, tanpa penyimpanan ke disk), PostgreSQL/MySQL (persistensi, tetapi lebih lambat) dan DynamoDB (untuk infrastruktur AWS).

Contoh struktur sesi di Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Server memperbarui lastAccess pada setiap permintaan, yang memungkinkan penerapan batas waktu tidak aktif — pengakhiran sesi otomatis setelah periode tidak ada aktivitas.

Cookie vs Header

Session Token dapat dikirim dengan dua cara: melalui HTTP cookie atau melalui header HTTP Authorization. Cookie — cara tradisional untuk aplikasi web: server mengatur cookie dengan flag HttpOnly (tidak dapat diakses JavaScript), Secure (hanya HTTPS) dan SameSite (perlindungan terhadap CSRF). Untuk aplikasi seluler, lebih sering digunakan header Authorization: Bearer <session_token>, karena mekanisme cookie tidak selalu nyaman di klien native.

Siklus Hidup Session Token

Siklus hidup session token mencakup tiga tahap: pembuatan, pemeliharaan sesi aktif, dan pengakhiran. Setiap tahap memerlukan konfigurasi keamanan yang tepat untuk mencegah kebocoran atau penyadapan token.

Pembuatan, penyimpanan, dan penghapusan

Pembuatan — server menghasilkan string acak yang aman secara kriptografis dengan panjang 128–256 bit (misalnya, melalui SecureRandom di Java atau os.urandom di Python). Token harus tidak dapat diprediksi — penggunaan UUID atau timestamp tanpa entropi tidak diperbolehkan. Penyimpanan di klien: di iOS — Keychain, di Android — EncryptedSharedPreferences, di web — HttpOnly cookie. Penghapusan terjadi saat logout: klien menghapus token dari penyimpanan, server menghapus catatan sesi dari Redis. Setelah logout, session token menjadi tidak berguna — server tidak akan menemukan catatan yang sesuai.

Menurut data SANS Institute, 2025, implementasi pengakhiran sesi yang benar (logout dengan pembersihan di server) mencegah hingga 70% serangan menggunakan token curian. Sangat penting tidak hanya menghapus token di klien, tetapi juga membatalkan sesi di server.

Session Token vs JWT

Session Token dan JWT mewakili dua pendekatan berbeda untuk autentikasi. Session Token — stateful (server menyimpan status), JWT — stateless (data di dalam token). Pilihan di antara keduanya tergantung pada arsitektur aplikasi dan persyaratan keamanan.

Kapan Memilih Session Token

Session Token lebih disukai ketika: pencabutan sesi segera diperlukan (perbankan, panel admin), aplikasi berjalan pada satu atau beberapa server dengan Redis bersama, data sesi besar dan tidak muat di JWT, atau ketika tim ingin meminimalkan risiko kebocoran data melalui decoding token. Dalam skenario seperti itu, session token memberikan pemblokiran akses segera saat aktivitas mencurigakan — cukup hapus satu catatan dari Redis dan semua sesi pengguna menjadi tidak valid.

Menurut data Redis, 2025, penggunaan TTL di tingkat kunci sesi (perintah EXPIRE) secara otomatis membersihkan sesi yang kedaluwarsa tanpa biaya tambahan untuk tugas latar belakang. Untuk sesi dengan TTL 1 jam dan beban 10.000 pengguna bersamaan dengan ukuran sesi 1 KB, Redis mengonsumsi sekitar 1 GB RAM, yang membuatnya efisien secara ekonomi untuk sebagian besar aplikasi.

Keamanan Session Token

Keamanan session token didasarkan pada dua prinsip: token harus tidak dapat diprediksi dan dilindungi saat transmisi dan penyimpanan. Ancaman utama — penyadapan token (man-in-the-middle, XSS), prediksinya (generasi lemah) dan fiksasi sesi (session fixation).

Perlindungan dari pencurian token

Perlindungan meliputi: penggunaan HTTPS untuk semua permintaan dengan token, pengaturan TTL sesi pendek (15–60 menit tidak aktif), pengikatan sesi ke IP dan user-agent (pemeriksaan tambahan pada setiap permintaan), penggunaan flag Secure dan HttpOnly untuk cookie, rotasi session token secara teratur setelah operasi sensitif (perubahan kata sandi, peningkatan hak). OWASP juga merekomendasikan implementasi Manajemen Sesi dengan invalidasi sesi lama saat membuat sesi baru setelah login — ini mencegah fiksasi sesi.

Menurut data OWASP ASVS, 2025, sesi harus terikat setidaknya pada dua faktor: token itu sendiri (yang dimiliki klien) dan IP/user-agent (yang diketahui server). Jika faktor-faktor ini tidak cocok, server harus mengakhiri sesi dan meminta autentikasi ulang.

Contoh Implementasi di Kotlin

Di bawah ini adalah contoh implementasi server session token di Kotlin menggunakan Spring Boot dan Redis. Server menghasilkan token yang aman secara kriptografis melalui SecureRandom, menyimpan sesi di Redis dengan TTL dan memeriksanya pada setiap permintaan. Kode mendemonstrasikan tiga operasi utama: pembuatan sesi, validasi, dan invalidasi.

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

Implementasi ini menggunakan JedisPool untuk koneksi thread-safe ke Redis. Metode createSession mengatur TTL 1 jam (3600 detik) — setelah periode ini Redis akan secara otomatis menghapus catatan. Metode validateSession mengembalikan null untuk sesi yang tidak ada atau kedaluwarsa, memungkinkan server memproses permintaan dengan token tidak valid dengan benar dan mengembalikan HTTP 401.