Session Token in der Anwendungsentwicklung — was es ist, Funktionsprinzip und Unterschiede zu JWT

Was ist ein Session Token?

Session Token (Sitzungskennung) ist eine eindeutige Zeichenfolge, die der Server nach der Benutzerauthentifizierung generiert und mit den Sitzungsdaten verknüpft. Der Token enthält keine Benutzerinformationen — er ist lediglich ein Schlüssel zu den auf dem Server gespeicherten Daten. Dieser Ansatz wird als Stateful-Authentifizierung bezeichnet: Der Server speichert den Zustand jeder aktiven Sitzung und überprüft ihn bei jeder Anfrage.

Zu den Sitzungsdaten gehören: Benutzer-ID, Anmeldezeit, IP-Adresse, User-Agent, Berechtigungsliste, letzte Aktivitätszeit. Wenn der Client eine Anfrage mit einem Session Token sendet, findet der Server den entsprechenden Eintrag im Sitzungsspeicher, überprüft seine Gültigkeit und ruft die Daten zur Verarbeitung der Anfrage ab. Fehlt der Sitzungseintrag oder ist er abgelaufen, gibt der Server einen Authentifizierungsfehler zurück und fordert eine erneute Anmeldung.

Laut OWASP, 2025 bleibt der Session Token der Standard für Anwendungen, die einen sofortigen Zugriffswiderruf erfordern — beispielsweise in Banksystemen und Unternehmensportalen, wo ein Administrator die Sitzung eines Benutzers sofort beenden können muss. In solchen Systemen bietet der Session Token eine vollständige Zugriffskontrolle, die für Stateless-Token ohne zusätzliche Blockierungsmechanismen nicht erreichbar ist.

Wie funktioniert ein Session Token

Der Prozess beginnt, wenn der Client die Anmeldedaten an den Authentifizierungsserver sendet. Der Server überprüft den Benutzernamen und das Passwort, erstellt einen Sitzungseintrag im Speicher (normalerweise Redis oder eine Datenbank) und gibt einen eindeutigen Session Token an den Client zurück. Der Client speichert den Token und sendet ihn mit jeder nachfolgenden Anfrage, und der Server überprüft jedes Mal die Existenz und Gültigkeit der Sitzung.

Serversitzung und Speicher

Redis ist der beliebteste Sitzungsspeicher dank der In-Memory-Speicherung und der TTL-Unterstützung (Time-to-Live). Jede Sitzung wird als Schlüssel-Wert-Paar gespeichert, wobei der Schlüssel der Session Token und der Wert ein JSON-Objekt mit den Sitzungsdaten ist. TTL entfernt automatisch abgelaufene Sitzungen. Alternativen: Memcached (nur Speicher, keine Persistenz auf der Festplatte), PostgreSQL/MySQL (persistent aber langsamer) und DynamoDB (für AWS-Infrastruktur).

Beispiel einer Sitzungsstruktur in Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. Der Server aktualisiert lastAccess bei jeder Anfrage, was die Implementierung eines Inaktivitäts-Timeouts ermöglicht — automatische Beendigung der Sitzung nach einer Zeit der Inaktivität.

Cookie vs Header

Session Token kann auf zwei Arten übertragen werden: über HTTP-Cookie oder über den Authorization-HTTP-Header. Cookies sind die traditionelle Methode für Webanwendungen: Der Server setzt ein Cookie mit den Flags HttpOnly (für JavaScript nicht zugänglich), Secure (nur HTTPS) und SameSite (CSRF-Schutz). Für mobile Anwendungen wird häufiger der Header Authorization: Bearer <session_token> verwendet, da der Cookie-Mechanismus in nativen Clients nicht immer praktikabel ist.

Lebenszyklus des Session Token

Der Lebenszyklus eines Session Token umfasst drei Phasen: Erstellung, Aufrechterhaltung der aktiven Sitzung und Beendigung. Jede Phase erfordert eine angemessene Sicherheitskonfiguration, um ein Durchsickern oder Abfangen des Tokens zu verhindern.

Erstellung, Speicherung und Löschung

Erstellung — der Server generiert eine kryptografisch sichere Zufallszeichenfolge von 128–256 Bit (z. B. über SecureRandom in Java oder os.urandom in Python). Der Token muss unvorhersehbar sein — die Verwendung von UUID oder Zeitstempel ohne Entropie ist nicht zulässig. Speicherung auf dem Client: unter iOS — Keychain, unter Android — EncryptedSharedPreferences, im Web — HttpOnly-Cookie. Löschung erfolgt beim Logout: Der Client entfernt den Token aus dem Speicher, der Server löscht den Sitzungseintrag aus Redis. Nach dem Logout wird der Session Token nutzlos — der Server findet keinen entsprechenden Eintrag.

Laut SANS Institute, 2025 verhindert die korrekte Implementierung der Sitzungsbeendigung (Logout mit serverseitiger Bereinigung) bis zu 70 % der Angriffe mit gestohlenen Token. Es ist entscheidend, den Token nicht nur auf dem Client zu löschen, sondern die Sitzung auch auf dem Server zu ungültig zu machen.

Session Token vs JWT

Session Token und JWT repräsentieren zwei unterschiedliche Ansätze zur Authentifizierung. Session Token ist stateful (der Server speichert den Zustand), JWT ist stateless (Daten innerhalb des Tokens). Die Wahl zwischen ihnen hängt von der Anwendungsarchitektur und den Sicherheitsanforderungen ab.

Wann Session Token wählen

Session Token ist vorzuziehen, wenn: sofortiger Sitzungswiderruf erforderlich ist (Banking, Admin-Panels), die Anwendung auf einem oder mehreren Servern mit gemeinsamem Redis läuft, die Sitzungsdaten groß sind und nicht in JWT passen, oder das Team das Risiko von Datenlecks durch Tokendekodierung minimieren möchte. In solchen Szenarien bietet der Session Token eine sofortige Zugriffssperrung bei verdächtiger Aktivität — ein einziger gelöschter Eintrag aus Redis macht alle Benutzersitzungen ungültig.

Laut Redis, 2025 bereinigt die Verwendung von TTL auf Sitzungsschlüsselebene (EXPIRE-Befehl) automatisch abgelaufene Sitzungen ohne Overhead für Hintergrundaufgaben. Bei Sitzungen mit einer TTL von 1 Stunde und einer Last von 10.000 gleichzeitigen Benutzern verbraucht Redis bei einer Sitzungsgröße von 1 KB etwa 1 GB RAM, was es für die meisten Anwendungen kosteneffizient macht.

Sicherheit des Session Token

Die Sicherheit des Session Token basiert auf zwei Prinzipien: Der Token muss unvorhersehbar und während der Übertragung und Speicherung geschützt sein. Die Hauptbedrohungen sind das Abfangen des Tokens (Man-in-the-Middle, XSS), seine Vorhersage (schwache Generierung) und die Sitzungsfixierung (Session Fixation).

Schutz vor Tokendiebstahl

Der Schutz umfasst: Verwendung von HTTPS für alle Anfragen mit Token, Festlegung einer kurzen Sitzungs-TTL (15–60 Minuten Inaktivität), Bindung der Sitzung an IP und User-Agent (zusätzliche Überprüfung bei jeder Anfrage), Verwendung der Secure- und HttpOnly-Flags für Cookies und regelmäßige Rotation des Session Token nach sensiblen Vorgängen (Passwortänderung, Rechteerweiterung). OWASP empfiehlt außerdem die Implementierung eines Sitzungsmanagements mit Ungültigmachung der alten Sitzung bei der Erstellung einer neuen nach dem Login — dies verhindert Session Fixation.

Laut OWASP ASVS, 2025 muss eine Sitzung an mindestens zwei Faktoren gebunden sein: den Token selbst (was der Client hat) und die IP/den User-Agent (was der Server weiß). Wenn diese Faktoren nicht übereinstimmen, sollte der Server die Sitzung beenden und eine erneute Authentifizierung verlangen.

Beispielimplementierung in Kotlin

Nachfolgend finden Sie ein Beispiel für eine serverseitige Session-Token-Implementierung in Kotlin mit Spring Boot und Redis. Der Server generiert einen kryptografisch sicheren Token über SecureRandom, speichert die Sitzung in Redis mit TTL und überprüft sie bei jeder Anfrage. Der Code demonstriert drei Hauptoperationen: Sitzungserstellung, Validierung und Ungültigmachung.

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

Diese Implementierung verwendet JedisPool für eine threadsichere Verbindung zu Redis. Die Methode createSession setzt eine TTL von 1 Stunde (3600 Sekunden) — nach diesem Zeitraum löscht Redis den Eintrag automatisch. Die Methode validateSession gibt für nicht vorhandene oder abgelaufene Sitzungen null zurück, sodass der Server eine Anfrage mit einem ungültigen Token korrekt verarbeiten und HTTP 401 zurückgeben kann.