Session Token i applikationsutveckling — vad det är, funktionsprincip och skillnader mot JWT

Vad är Session Token?

Session Token (sessionsidentifierare) — är en unik sträng som servern genererar och kopplar till sessionsdata efter autentisering av användaren. Token innehåller ingen information om användaren — det är bara en nyckel till data som lagras på servern. Detta tillvägagångssätt kallas stateful-autentisering: servern lagrar tillståndet för varje aktiv session och kontrollerar det vid varje förfrågan.

Sessionsdata inkluderar: användaridentifierare, inloggningstid, IP-adress, user-agent, behörighetslista (permissions), tid för senaste aktiviteten. När klienten skickar en förfrågan med session token, hittar servern motsvarande post i sessionslagringen, kontrollerar dess giltighet och hämtar data för att behandla förfrågan. Om sessionsposten saknas eller har upphört, returnerar servern ett autentiseringsfel och kräver ny inloggning.

Enligt data från OWASP, 2025, förblir session token standarden för applikationer som kräver omedelbar återkallelse av åtkomst — till exempel i banksystem och företagsportaler, där administratören måste kunna avsluta en användares session omedelbart. I sådana system ger session token fullständig kontroll över åtkomst, ouppnåelig för stateless-token utan ytterligare blockeringsmekanismer.

Hur fungerar Session Token

Arbetsprocessen börjar när klienten skickar inloggningsuppgifter till autentiseringsservern. Servern kontrollerar användarnamn och lösenord, skapar en sessionspost i lagringen (vanligtvis Redis eller databas) och returnerar en unik session token till klienten. Klienten sparar token och skickar den med varje efterföljande förfrågan, och servern kontrollerar varje gång sessionens existens och giltighet.

Serversession och lagring

Redis — den mest populära sessionslagringen tack vare in-memory-lagring och stöd för TTL (time-to-live). Varje session lagras som ett nyckel-värde-par, där nyckeln är session token och värdet är ett JSON-objekt med sessionsdata. TTL tar automatiskt bort utgångna sessioner. Alternativ: Memcached (endast minne, utan lagring på disk), PostgreSQL/MySQL (beståndighet men långsammare) och DynamoDB (för AWS-infrastruktur).

Exempel på sessionsstruktur i Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Servern uppdaterar lastAccess vid varje förfrågan, vilket gör det möjligt att implementera en inaktivitets timeout — automatisk avslutning av sessionen efter en period av inaktivitet.

Cookie vs Header

Session Token kan överföras på två sätt: via HTTP-cookie eller via HTTP-huvudet Authorization. Cookie — traditionellt sätt för webbapplikationer: servern anger en cookie med flaggorna HttpOnly (inte tillgänglig från JavaScript), Secure (endast HTTPS) och SameSite (skydd mot CSRF). För mobilapplikationer används oftare huvudet Authorization: Bearer <session_token>, eftersom cookie-mekanismen inte alltid är bekväm i native-klienter.

Livscykel för Session Token

Livscykeln för session token omfattar tre faser: skapande, underhåll av aktiv session och avslutning. Varje fas kräver korrekt säkerhetskonfiguration för att förhindra läckage eller avlyssning av token.

Skapa, lagra och ta bort

Skapa — servern genererar en kryptografiskt säker slumpmässig sträng med längden 128–256 bitar (t.ex. via SecureRandom i Java eller os.urandom i Python). Token måste vara oförutsägbar — användning av UUID eller tidsstämpel utan entropi är inte tillåten. Lagring på klienten: i iOS — Keychain, i Android — EncryptedSharedPreferences, på webben — HttpOnly-cookie. Borttagning sker vid utloggning: klienten tar bort token från lagringen, servern tar bort sessionsposten från Redis. Efter utloggning blir session token oanvändbar — servern hittar ingen motsvarande post.

Enligt data från SANS Institute, 2025, förhindrar korrekt implementering av sessionsavslutning (utloggning med rensning på servern) upp till 70% av attacker med stulna token. Det är kritiskt viktigt att inte bara ta bort token på klienten utan även annullera sessionen på servern.

Session Token vs JWT

Session Token och JWT representerar två olika angreppssätt för autentisering. Session Token — stateful (servern lagrar tillståndet), JWT — stateless (data inuti token). Valet mellan dem beror på applikationsarkitekturen och säkerhetskraven.

När ska du välja Session Token

Session Token är att föredra när: omedelbar återkallelse av sessioner krävs (banktjänster, administrationspaneler), applikationen körs på en eller flera servrar med delad Redis, sessionsdata är stor och får inte plats i JWT, eller när teamet vill minimera risken för dataläckage via avkodning av token. I sådana scenarier ger session token omedelbar åtkomstblockering vid misstänkt aktivitet — ta bara bort en post från Redis och alla användarens sessioner blir ogiltiga.

Enligt data från Redis, 2025, rensar användning av TTL på sessionsnyckelnivå (kommandot EXPIRE) automatiskt utgångna sessioner utan extra kostnad för bakgrundsuppgifter. För sessioner med TTL på 1 timme och en belastning på 10 000 samtidiga användare med sessionsstorlek på 1 KB förbrukar Redis cirka 1 GB RAM, vilket gör det ekonomiskt effektivt för de flesta applikationer.

Säkerhet för Session Token

Säkerheten för session token baseras på två principer: token måste vara oförutsägbar och skyddad under överföring och lagring. De huvudsakliga hoten — avlyssning av token (man-in-the-middle, XSS), förutsägelse av den (svag generering) och sessionsfixering (session fixation).

Skydd mot stöld av token

Skydd inkluderar: användning av HTTPS för alla förfrågningar med token, inställning av kort sessions-TTL (15–60 minuters inaktivitet), bindning av sessionen till IP och user-agent (extra kontroll vid varje förfrågan), användning av Secure- och HttpOnly-flaggor för cookies, regelbunden rotation av session token efter känsliga operationer (ändring av lösenord, höjning av behörigheter). OWASP rekommenderar också att implementera Sessionshantering med ogiltigförklaring av den gamla sessionen när en ny skapas efter inloggning — detta förhindrar sessionsfixering.

Enligt data från OWASP ASVS, 2025, bör sessionen vara bunden till minst två faktorer: själva token (vad klienten har) och IP/user-agent (vad servern vet). Om dessa faktorer inte matchar, bör servern avsluta sessionen och kräva ny autentisering.

Exempel på implementering i Kotlin

Nedan finns ett exempel på serverimplementering av session token i Kotlin med Spring Boot och Redis. Servern genererar en kryptografiskt säker token via SecureRandom, lagrar sessionen i Redis med TTL och kontrollerar den vid varje förfrågan. Koden visar tre huvudoperationer: att skapa session, validering och ogiltigförklaring.

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

Denna implementering använder JedisPool för trådsäker anslutning till Redis. Metoden createSession anger en TTL på 1 timme (3600 sekunder) — efter denna tid kommer Redis automatiskt att ta bort posten. Metoden validateSession returnerar null för icke-existerande eller utgångna sessioner, vilket gör att servern kan behandla en förfrågan med ogiltig token korrekt och returnera HTTP 401.