Session Token sa pag-develop ng aplikasyon — ano ito, prinsipyo ng paggana, at mga pagkakaiba sa JWT

Ano ang Session Token?

Session Token (identifier ng session) — ay isang natatanging string na ginagawa ng server at iniuugnay sa data ng session pagkatapos ng pag-authenticate ng user. Ang token ay walang nilalaman na impormasyon tungkol sa user — ito ay susi lamang sa data na naka-imbak sa server. Ang pamamaraang ito ay tinatawag na stateful authentication: iniimbak ng server ang estado ng bawat aktibong session at sinusuri ito sa bawat kahilingan.

Ang data ng session ay kinabibilangan ng: identifier ng user, oras ng pag-login, IP address, user-agent, listahan ng mga pahintulot (permissions), oras ng huling aktibidad. Kapag nagpadala ang client ng kahilingan na may session token, hinahanap ng server ang kaukulang record sa imbakan ng session, sinusuri ang bisa nito, at kinukuha ang data para sa pagproseso ng kahilingan. Kung ang session record ay wala o nag-expire na, nagbabalik ang server ng error sa pag-authenticate at nangangailangan ng muling pag-login.

Ayon sa datos ng OWASP, 2025, ang session token ay nananatiling pamantayan para sa mga application na nangangailangan ng agarang pagbawi ng access — halimbawa, sa mga banking system at corporate portal, kung saan ang administrator ay dapat na agad na matapos ang session ng user. Sa ganitong mga sistema, ang session token ay nagbibigay ng ganap na kontrol sa access, na hindi maaabot ng mga stateless token nang walang karagdagang mekanismo ng pag-block.

Paano Gumagana ang Session Token

Ang proseso ng paggana ay nagsisimula kapag ang client ay nagpadala ng mga kredensyal sa server ng pag-authenticate. Sinusuri ng server ang login at password, gumagawa ng session record sa imbakan (karaniwan ay Redis o database) at nagbabalik ng natatanging session token sa client. Iniimbak ng client ang token at ipinapadala ito sa bawat kasunod na kahilingan, at sinusuri ng server sa bawat oras ang pagkakaroon at bisa ng session.

Server session at imbakan

Redis — ang pinakasikat na imbakan ng session dahil sa in-memory storage at suporta sa TTL (time-to-live). Ang bawat session ay naka-imbak bilang key-value pair, kung saan ang key ay session token, at ang value ay JSON object na may data ng session. Awtomatikong tinatanggal ng TTL ang mga expired na session. Mga alternatibo: Memcached (memorya lamang, walang imbakan sa disk), PostgreSQL/MySQL (persistence, ngunit mas mabagal) at DynamoDB (para sa AWS infrastructure).

Halimbawa ng istraktura ng session sa Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Ina-update ng server ang lastAccess sa bawat kahilingan, na nagpapahintulot sa pagpapatupad ng timeout ng kawalan ng aktibidad — awtomatikong pagtatapos ng session pagkatapos ng panahon ng kawalan ng aktibidad.

Cookie vs Header

Session Token ay maaaring ipadala sa dalawang paraan: sa pamamagitan ng HTTP cookie o sa pamamagitan ng HTTP Authorization header. Cookie — tradisyonal na paraan para sa web applications: nagtatakda ang server ng cookie na may mga flag na HttpOnly (hindi accessible sa JavaScript), Secure (HTTPS lamang) at SameSite (proteksyon laban sa CSRF). Para sa mobile applications, mas madalas ginagamit ang header na Authorization: Bearer <session_token>, dahil ang mekanismo ng cookie ay hindi palaging maginhawa sa native clients.

Siklo ng Buhay ng Session Token

Ang siklo ng buhay ng session token ay may tatlong yugto: paggawa, pagpapanatili ng aktibong session, at pagtatapos. Ang bawat yugto ay nangangailangan ng tamang configuration ng seguridad upang maiwasan ang pagtagas o pagharang ng token.

Paggawa, pag-iimbak, at pagtanggal

Paggawa — ang server ay gumagawa ng cryptographically secure random string na may haba na 128–256 bits (halimbawa, sa pamamagitan ng SecureRandom sa Java o os.urandom sa Python). Ang token ay dapat na hindi mahulaan — ang paggamit ng UUID o timestamp na walang entropy ay hindi pinapayagan. Pag-iimbak sa client: sa iOS — Keychain, sa Android — EncryptedSharedPreferences, sa web — HttpOnly cookie. Pagtanggal ay nangyayari kapag nag-logout: tinatanggal ng client ang token mula sa imbakan, tinatanggal ng server ang session record mula sa Redis. Pagkatapos mag-logout, ang session token ay nagiging walang silbi — hindi makikita ng server ang kaukulang record.

Ayon sa datos ng SANS Institute, 2025, ang tamang implementasyon ng pagtatapos ng session (logout na may paglilinis sa server) ay pumipigil sa hanggang 70% ng mga pag-atake gamit ang ninakaw na token. Mahalaga hindi lamang tanggalin ang token sa client, kundi pati na rin bawiin ang session sa server.

Session Token vs JWT

Session Token at JWT ay kumakatawan sa dalawang magkaibang diskarte sa pag-authenticate. Session Token — stateful (iniimbak ng server ang estado), JWT — stateless (data sa loob ng token). Ang pagpili sa pagitan ng mga ito ay nakadepende sa arkitektura ng application at mga kinakailangan sa seguridad.

Kailan Pumili ng Session Token

Session Token ay mas gusto kapag: kinakailangan ang agarang pagbawi ng mga session (banking, admin panels), ang application ay tumatakbo sa isa o maraming server na may shared Redis, ang data ng session ay malaki at hindi kasya sa JWT, o kapag gusto ng team na mabawasan ang panganib ng pagtagas ng data sa pamamagitan ng pag-decode ng token. Sa ganitong mga sitwasyon, ang session token ay nagbibigay ng agarang pag-block ng access sa kahina-hinalang aktibidad — tanggalin lang ang isang record mula sa Redis at lahat ng session ng user ay magiging invalid.

Ayon sa datos ng Redis, 2025, ang paggamit ng TTL sa antas ng session key (EXPIRE command) ay awtomatikong naglilinis ng mga expired na session nang walang dagdag na gastos para sa background tasks. Para sa mga session na may TTL na 1 oras at load na 10,000 kasabay na user na may session size na 1 KB, ang Redis ay kumokonsumo ng humigit-kumulang 1 GB ng RAM, na ginagawang matipid ito para sa karamihan ng mga application.

Seguridad ng Session Token

Ang seguridad ng session token ay batay sa dalawang prinsipyo: ang token ay dapat na hindi mahulaan at protektado sa panahon ng pagpapadala at pag-iimbak. Ang mga pangunahing banta — pagharang ng token (man-in-the-middle, XSS), paghula nito (mahinang paggawa) at session fixation.

Proteksyon laban sa pagnanakaw ng token

Proteksyon ay kinabibilangan ng: paggamit ng HTTPS para sa lahat ng kahilingan na may token, pagtatakda ng maikling TTL ng session (15–60 minuto ng kawalan ng aktibidad), pag-uugnay ng session sa IP at user-agent (karagdagang pagsusuri sa bawat kahilingan), paggamit ng Secure at HttpOnly flag para sa cookie, regular na pag-ikot ng session token pagkatapos ng mga sensitibong operasyon (pagbabago ng password, pagtaas ng pribilehiyo). Inirerekomenda din ng OWASP ang pagpapatupad ng Pamamahala ng Session na may invalidation ng lumang session kapag gumagawa ng bago pagkatapos mag-login — ito ay pumipigil sa session fixation.

Ayon sa datos ng OWASP ASVS, 2025, ang session ay dapat na nakaugnay sa hindi bababa sa dalawang factor: ang token mismo (kung ano ang nasa client) at IP/user-agent (kung ano ang alam ng server). Kung hindi magkatugma ang mga factor na ito, dapat tapusin ng server ang session at humiling ng muling pag-authenticate.

Halimbawa ng Implementasyon sa Kotlin

Sa ibaba ay isang halimbawa ng server implementasyon ng session token sa Kotlin gamit ang Spring Boot at Redis. Ang server ay gumagawa ng cryptographically secure token sa pamamagitan ng SecureRandom, nag-iimbak ng session sa Redis na may TTL at sinusuri ito sa bawat kahilingan. Ang code ay nagpapakita ng tatlong pangunahing operasyon: paggawa ng session, validation, at invalidation.

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

Ang implementasyong ito ay gumagamit ng JedisPool para sa thread-safe na koneksyon sa Redis. Ang pamamaraang createSession ay nagtatakda ng TTL na 1 oras (3600 segundo) — pagkatapos ng panahong ito, awtomatikong tatanggalin ng Redis ang record. Ang pamamaraang validateSession ay nagbabalik ng null para sa mga hindi umiiral o expired na session, na nagpapahintulot sa server na iproseso nang tama ang kahilingan na may invalid na token at magbalik ng HTTP 401.