Session Token in applicatieontwikkeling — wat het is, werkingsprincipe en verschillen met JWT

Wat is een Session Token?

Session Token (sessie-ID) — is een unieke reeks die de server genereert en koppelt aan sessiegegevens na authenticatie van de gebruiker. De token bevat geen informatie over de gebruiker — het is slechts een sleutel tot de gegevens die op de server zijn opgeslagen. Deze benadering wordt stateful-authenticatie genoemd: de server slaat de status van elke actieve sessie op en controleert deze bij elk verzoek.

Sessiegegevens omvatten: gebruikers-ID, inlogtijd, IP-adres, user-agent, lijst met machtigingen (permissions), tijd van laatste activiteit. Wanneer de client een verzoek met een session token verzendt, vindt de server de bijbehorende record in de sessieopslag, controleert de geldigheid ervan en haalt de gegevens op voor verwerking van het verzoek. Als de sessierecord ontbreekt of is verlopen, retourneert de server een authenticatiefout en vraagt om opnieuw inloggen.

Volgens gegevens van OWASP, 2025, blijft session token de standaard voor applicaties die onmiddellijke intrekking van toegang vereisen — bijvoorbeeld in banksystemen en bedrijfsportalen, waar een beheerder de sessie van een gebruiker onmiddellijk moet kunnen beëindigen. In dergelijke systemen biedt session token volledige controle over toegang, die onbereikbaar is voor stateless-tokens zonder aanvullende blokkeringsmechanismen.

Hoe werkt een Session Token

Het werkproces begint wanneer de client inloggegevens naar de authenticatieserver verzendt. De server controleert de gebruikersnaam en het wachtwoord, maakt een sessierecord aan in de opslag (meestal Redis of database) en retourneert een unieke session token aan de client. De client slaat de token op en verzendt deze met elk volgend verzoek, en de server controleert elke keer het bestaan en de geldigheid van de sessie.

Serversessie en opslag

Redis — de populairste sessieopslag vanwege in-memory opslag en ondersteuning voor TTL (time-to-live). Elke sessie wordt opgeslagen als een sleutel-waardepaar, waarbij de sleutel de session token is en de waarde een JSON-object met sessiegegevens. TTL verwijdert automatisch verlopen sessies. Alternatieven: Memcached (alleen geheugen, zonder opslag op schijf), PostgreSQL/MySQL (persistentie, maar langzamer) en DynamoDB (voor AWS-infrastructuur).

Voorbeeld van sessiestructuur in Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. De server werkt lastAccess bij bij elk verzoek, wat het mogelijk maakt een inactiviteitstimeout te implementeren — automatische beëindiging van de sessie na een periode van inactiviteit.

Cookie vs Header

Session Token kan op twee manieren worden verzonden: via HTTP-cookie of via de HTTP-header Authorization. Cookie — traditionele methode voor webapplicaties: de server stelt een cookie in met de vlaggen HttpOnly (niet toegankelijk via JavaScript), Secure (alleen HTTPS) en SameSite (bescherming tegen CSRF). Voor mobiele applicaties wordt vaker de header Authorization: Bearer <session_token> gebruikt, omdat het cookie-mechanisme niet altijd handig is in native clients.

Levenscyclus van Session Token

De levenscyclus van een session token omvat drie fasen: aanmaken, onderhouden van een actieve sessie en beëindigen. Elke fase vereist correcte beveiligingsconfiguratie om lekkage of onderschepping van de token te voorkomen.

Aanmaken, opslaan en verwijderen

Aanmaken — de server genereert een cryptografisch veilige willekeurige reeks van 128–256 bits (bijv. via SecureRandom in Java of os.urandom in Python). De token moet onvoorspelbaar zijn — gebruik van UUID of tijdstempel zonder entropie is niet toegestaan. Opslaan op de client: in iOS — Keychain, in Android — EncryptedSharedPreferences, op het web — HttpOnly-cookie. Verwijderen vindt plaats bij uitloggen: de client verwijdert de token uit de opslag, de server verwijdert het sessierecord uit Redis. Na uitloggen wordt de session token nutteloos — de server zal geen bijbehorende record vinden.

Volgens gegevens van SANS Institute, 2025, voorkomt correcte implementatie van sessiebeëindiging (uitloggen met opschonen op de server) tot 70% van aanvallen met gestolen tokens. Het is van cruciaal belang om niet alleen de token op de client te verwijderen, maar ook de sessie op de server in te trekken.

Session Token vs JWT

Session Token en JWT vertegenwoordigen twee verschillende benaderingen van authenticatie. Session Token — stateful (server slaat de status op), JWT — stateless (gegevens in de token). De keuze tussen hen hangt af van de applicatiearchitectuur en beveiligingsvereisten.

Wanneer Session Token kiezen

Session Token heeft de voorkeur wanneer: onmiddellijke intrekking van sessies vereist is (bankieren, beheerpanelen), de applicatie op een of meerdere servers met gedeelde Redis draait, sessiegegevens groot zijn en niet in JWT passen, of wanneer het team het risico op gegevenslekkage via decodering van de token wil minimaliseren. In dergelijke scenario's biedt session token onmiddellijke toegangsblokkering bij verdachte activiteit — verwijder gewoon een record uit Redis en alle sessies van de gebruiker worden ongeldig.

Volgens gegevens van Redis, 2025, verwijdert het gebruik van TTL op sessiesleutelniveau (EXPIRE-commando) automatisch verlopen sessies zonder extra kosten voor achtergrondtaken. Voor sessies met een TTL van 1 uur en een belasting van 10.000 gelijktijdige gebruikers verbruikt Redis ongeveer 1 GB RAM bij een sessiegrootte van 1 KB, wat het economisch efficiënt maakt voor de meeste applicaties.

Veiligheid van Session Token

De veiligheid van session token is gebaseerd op twee principes: de token moet onvoorspelbaar en beschermd zijn tijdens verzending en opslag. De belangrijkste bedreigingen — onderschepping van de token (man-in-the-middle, XSS), het voorspellen ervan (zwakke generatie) en sessiefixatie (session fixation).

Bescherming tegen diefstal van de token

Bescherming omvat: gebruik van HTTPS voor alle verzoeken met de token, instellen van een korte sessie-TTL (15–60 minuten inactiviteit), koppeling van de sessie aan IP en user-agent (extra controle bij elk verzoek), gebruik van Secure- en HttpOnly-vlaggen voor cookies, regelmatige rotatie van de session token na gevoelige bewerkingen (wachtwoordwijziging, verhoging van rechten). OWASP beveelt ook aan om Sessiebeheer te implementeren met invalidatie van de oude sessie bij het aanmaken van een nieuwe na het inloggen — dit voorkomt sessiefixatie.

Volgens gegevens van OWASP ASVS, 2025, moet de sessie aan ten minste twee factoren worden gekoppeld: de token zelf (wat de client heeft) en IP/user-agent (wat de server weet). Bij niet-overeenkomen van deze factoren moet de server de sessie beëindigen en opnieuw authenticatie vereisen.

Voorbeeldimplementatie in Kotlin

Hieronder staat een voorbeeld van een serverimplementatie van session token in Kotlin met Spring Boot en Redis. De server genereert een cryptografisch veilige token via SecureRandom, slaat de sessie op in Redis met TTL en controleert deze bij elk verzoek. De code demonstreert drie hoofdoperaties: sessie aanmaken, valideren en invalidatie.

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

Deze implementatie gebruikt JedisPool voor een thread-veilige verbinding met Redis. De methode createSession stelt een TTL in van 1 uur (3600 seconden) — na deze periode verwijdert Redis automatisch de record. De methode validateSession retourneert null voor niet-bestaande of verlopen sessies, waardoor de server een verzoek met een ongeldige token correct kan verwerken en HTTP 401 kan retourneren.