Sitzungen & Token-Rotation

Wenn sich ein Benutzer bei einer von Auris betriebenen Anwendung anmeldet, erstellt das System eine Sitzung. Diese Sitzung ist der maßgebliche Datensatz für den authentifizierten Zustand des Benutzers. Das Verständnis, wie Sitzungen funktionieren, wie Tokens rotiert werden und wie Auris Token-Diebstahl erkennt, ist für die Entwicklung sicherer Anwendungen und die Fehlerbehebung bei Authentifizierungsproblemen unerlässlich.

Was ist eine Sitzung in Auris?

Eine Sitzung in Auris ist ein serverseitiger Datensatz, der in der Datenbank (über Prisma) gespeichert wird, kein clientseitiges Cookie oder Token. Jede Sitzung enthält:

Der entscheidende Unterschied zu vielen anderen Auth-Anbietern: Auris-Sitzungen sind server-autoritativ. Der Server weiß immer, welche Sitzungen existieren, welche aktiv sind, und kann jede Sitzung sofort widerrufen. Es wird nicht allein auf den Token-Ablauf zur Sitzungsbeendigung vertraut.

Sitzungslebenszyklus

Eine Sitzung durchläuft einen klar definierten Lebenszyklus von der Erstellung bis zur Beendigung:

Sitzungserstellung

Wenn die Authentifizierung erfolgreich ist (nach allen Faktoren einschließlich MFA, adaptiver Risikoprüfungen und Actions-Engine-Hooks), führt Auris folgendes aus:

1. Erstellt einen OAuthSession-Datensatz in der Datenbank
2. Generiert einen zufälligen sessionToken und setzt ihn als httpOnly-Cookie (30-Minuten-TTL, bei jeder Verwendung erneuert)
3. Stellt ein Zugriffstoken (signiertes JWT) mit den Claims, Rollen und benutzerdefinierten Claims des Benutzers aus
4. Stellt einen Refresh-Token aus (opaker rt_-präfixierter String)
5. Weist einen tokenFamily-Bezeichner zu, der alle zukünftigen Refresh-Tokens in dieser Sitzung verknüpft

Aktive Nutzung

Während der aktiven Lebensdauer der Sitzung sendet der Client das Zugriffstoken bei jeder API-Anfrage. Der Ressourcenserver validiert die JWT-Signatur lokal (via JWKS), ohne Auris zu kontaktieren. Für die Zugriffstoken-Validierung findet keine Datenbankabfrage statt, was die Latenz niedrig hält.

Aktualisierung

Wenn das Zugriffstoken abläuft, sendet der Client den Refresh-Token an den Token-Endpunkt. Auris:

1. Sucht den Refresh-Token in der Datenbank
2. Prüft, ob er noch nicht verwendet wurde (Rotationsprüfung)
3. Prüft, ob die Sitzung nicht abgelaufen ist (absolute und gleitende Prüfungen)
4. Invalidiert den alten Refresh-Token (markiert ihn als verwendet)
5. Stellt ein neues Zugriffstoken und einen neuen Refresh-Token aus
6. Aktualisiert lastActiveAt in der Sitzung (setzt das gleitende Fenster zurück)

Beendigung

Sitzungen werden durch verschiedene Mechanismen beendet, die jeweils für ein anderes Szenario konzipiert sind:

Refresh-Token-Rotation

Die Refresh-Token-Rotation ist ein Sicherheitsmechanismus, bei dem jede erfolgreiche Token-Aktualisierung den alten Refresh-Token invalidiert und einen neuen ausstellt. Auris implementiert die Rotation standardmäßig ohne Abmeldemöglichkeit.

Warum rotieren?

Ohne Rotation bleibt ein gestohlener Refresh-Token bis zu seinem natürlichen Ablauf (standardmäßig 7 Tage) gültig. Der Angreifer kann ihn verwenden, um innerhalb dieses Fensters unbegrenzt neue Zugriffstoken zu erhalten, selbst wenn der legitime Benutzer die Anwendung weiterhin nutzt.

Mit Rotation kann ein gestohlener Refresh-Token nur einmal verwendet werden. Wenn der legitime Benutzer zuerst aktualisiert (was der häufige Fall ist), wird das gestohlene Token ungültig. Wenn der Angreifer zuerst aktualisiert, löst der nächste Aktualisierungsversuch des legitimen Benutzers die Wiederverwendungserkennung aus.

Funktionsweise

Jeder Refresh-Token in Auris wird in der Datenbank mit folgenden Metadaten gespeichert:

{
  token: "rt_7fKp2mXa9qN3vB8yR4tL1wC6jD5sE0uH",
  tokenFamily: "fam_abc123",
  used: false,
  createdAt: "2025-02-10T08:15:00Z",
  sessionId: "sess_xyz789"
}

Wenn eine Aktualisierungsanfrage eingeht:

1. Token-Suche: Den Refresh-Token in der Datenbank finden
2. Verwendungsprüfung: Wenn used: true, ist dies ein Wiederverwendungsversuch (siehe Wiederverwendungserkennung)
3. Als verwendet markieren: used: true auf dem aktuellen Token setzen
4. Neue Tokens ausstellen: Einen neuen Refresh-Token mit derselben tokenFamily und used: false erstellen
5. Zurückgeben: Das neue Zugriffstoken + Refresh-Token an den Client senden

// Anfrage
POST /api/auth/token
{
  "grant_type": "refresh_token",
  "refresh_token": "rt_7fKp2mXa9qN3vB8yR4tL1wC6jD5sE0uH"
}
 
// Antwort
{
  "ok": true,
  "data": {
    "accessToken": "eyJhbGciOiJSUzI1NiJ9...",
    "refreshToken": "rt_NEW_rotated_token_here...",
    "expiresIn": 900
  }
}

Refresh-Token-Wiederverwendungserkennung

Die Wiederverwendungserkennung ist der Mechanismus, der Token-Diebstahl aufdeckt. Wenn ein bereits verwendeter Refresh-Token am Token-Endpunkt präsentiert wird, geht Auris davon aus, dass das Token gestohlen wurde, und ergreift defensive Maßnahmen.

Das Angriffsszenario

1. Benutzerin Alice meldet sich an. Sie erhält Refresh-Token RT-1.
2. Angreifer stiehlt RT-1 (über XSS, Netzwerkabfangen oder Gerätekompromittierung).
3. Fall A: Alice aktualisiert zuerst. RT-1 wird als verwendet markiert. Sie erhält RT-2. Später versucht der Angreifer, RT-1 zu verwenden. Auris sieht, dass RT-1 bereits verwendet wurde. Wiederverwendung erkannt.
4. Fall B: Angreifer aktualisiert zuerst. RT-1 wird als verwendet markiert. Angreifer erhält RT-2a. Später versucht Alice, RT-1 zu verwenden. Auris sieht, dass RT-1 bereits verwendet wurde. Wiederverwendung erkannt.

In beiden Fällen weiß Auris, dass etwas nicht stimmt, weil ein verwendetes Token präsentiert wurde.

Was bei Wiederverwendungserkennung passiert

Bei erkannter Wiederverwendung widerruft Auris die gesamte Token-Familie:

1. Jeder Refresh-Token mit derselben tokenFamily wird invalidiert
2. Die mit der Familie verknüpfte Sitzung wird beendet
3. Ein Audit-Protokolleintrag wird mit action: 'TOKEN_REUSE_DETECTED' erstellt
4. Wenn der Benutzer Benachrichtigungseinstellungen hat, wird eine Verdachts-Login-Benachrichtigung gesendet

Sowohl der legitime Benutzer als auch der Angreifer werden abgemeldet. Der legitime Benutzer muss sich erneut authentifizieren. Dies ist ein bewusster Sicherheitskompromiss: Eine kurze Unannehmlichkeit für den Benutzer ist dem Erlauben, ein gestohlenes Token weiter zu verwenden, vorzuziehen.

Token-Familien und Sitzungsbindung

Eine Token-Familie ist eine Kette von Refresh-Tokens, die mit einer einzigen Sitzung verknüpft sind. Wenn eine Sitzung erstellt wird, wird ein eindeutiger tokenFamily-Bezeichner generiert. Jeder innerhalb dieser Sitzung ausgestellte Refresh-Token teilt dieselbe Familien-ID.

Sitzung erstellt → tokenFamily: "fam_abc123"
  └─ RT-1 (fam_abc123) → verwendet → RT-2 (fam_abc123) → verwendet → RT-3 (fam_abc123) → aktiv

Token-Familien dienen zwei Zwecken:

1. Wiederverwendungserkennungsumfang: Wenn ein wiederverwendetes Token erkannt wird, kann Auris alle Tokens in der Familie identifizieren und widerrufen, nicht nur das einzelne Token.
2. Sitzungskorrelation: Alle Tokens in einer Familie führen zur gleichen Sitzung und zum gleichen ursprünglichen Authentifizierungsereignis zurück. Dies macht Audit-Trails kohärent.

Ein Benutzer kann mehrere aktive Token-Familien haben — eine pro Gerät/Sitzung. Das Widerrufen einer Familie betrifft andere Familien desselben Benutzers nicht.

Absoluter vs. Gleitender Ablauf

Auris unterstützt zwei Ablaufmodelle für Sitzungen, die beide gleichzeitig aktiv sein können:

Gleitender Ablauf (Inaktivitäts-Timeout)

Die Sitzung läuft ab, wenn der Benutzer seine Tokens nicht innerhalb eines konfigurierten Fensters aktualisiert. Jede erfolgreiche Aktualisierung setzt den gleitenden Timer zurück.

• Standard: 7 Tage Inaktivität
• Anwendungsfall: Inaktive Benutzer automatisch abmelden
• Verhalten: lastActiveAt wird bei jeder Aktualisierung aktualisiert. Wenn now - lastActiveAt > slidingWindow, ist die Sitzung abgelaufen.

Absoluter Ablauf (Maximale Sitzungslebensdauer)

Die Sitzung läuft nach einer festen Dauer ab der Erstellung ab, unabhängig von der Aktivität.

• Standard: 30 Tage ab Sitzungserstellung
• Anwendungsfall: Periodische Neuthentifizierung für die Sicherheits-Compliance erzwingen
• Verhalten: now - createdAt > absoluteMax löst den Ablauf aus, auch wenn der Benutzer kontinuierlich aktiv war

Konfiguration

Beide Werte werden in der Auris-Konsole unter Einstellungen → Sicherheit → Sitzungsrichtlinien konfiguriert:

Wenn beide konfiguriert sind, läuft die Sitzung ab, was auch immer zuerst eintritt. Zum Beispiel mit einem 7-Tage-Gleitfenster und 30-Tage-Absolutmaximum:

• Ein Benutzer, der täglich aktiv ist, wird nach 30 Tagen abgemeldet und muss sich erneut authentifizieren
• Ein Benutzer, der die Anwendung aufhört zu nutzen, wird nach 7 Tagen Inaktivität abgemeldet

Multi-Gerät-Sitzungen

Jedes Gerät oder Browser, auf dem sich ein Benutzer anmeldet, erstellt eine separate, unabhängige Sitzung. Sitzungen werden nicht geräteübergreifend geteilt.

Funktionsweise

• Alice meldet sich auf ihrem Laptop an. Sitzung S1 wird mit Token-Familie F1 erstellt.
• Alice meldet sich auf ihrem Telefon an. Sitzung S2 wird mit Token-Familie F2 erstellt.
• Alice meldet sich auf einem gemeinsam genutzten Computer an. Sitzung S3 wird mit Token-Familie F3 erstellt.

Jede Sitzung hat ihr eigenes:

• Sitzungsdatensatz in der Datenbank
• Token-Familie
• Unabhängige Ablauf-Timer (gleitend und absolut)
• Unabhängige Refresh-Token-Rotationskette

Sitzungsverwaltung

Benutzer können ihre aktiven Sitzungen über die Konto-Sicherheitsseite anzeigen und verwalten. Administratoren können Sitzungen für jeden Benutzer in der Auris-Konsole unter Benutzer → (Benutzer auswählen) → Sitzungen verwalten.

Verfügbare Aktionen:

Sitzungsmetadaten

Jede Sitzung speichert zum Erstellungszeitpunkt erfasste Metadaten:

• IP-Adresse: Die IP, von der der Login erfolgte
• User Agent: Der Browser oder Client-Bezeichner
• Ungefährer Standort: Stadt/Land aus GeoIP (wenn die Verdachts-Login-Erkennung aktiviert ist)
• Zuletzt aktiv: Wann die Sitzung zuletzt verwendet (aktualisiert) wurde

Diese Metadaten werden in der Sitzungsliste angezeigt und helfen Benutzern, unbekannte Sitzungen zu identifizieren.

Beziehung zwischen Keycloak-Sitzungen und Auris-Sitzungen

Auris verwendet Keycloak als zugrundeliegenden Identity Provider. Wenn sich ein Benutzer authentifiziert, existieren zwei Sitzungen:

Keycloak-Sitzung

Die Keycloak-Sitzung wird erstellt, wenn der Benutzer sich gegen Keycloak authentifiziert (Passwortverifizierung, Social-Login-Callback, SAML-Assertion). Keycloak verwaltet seinen eigenen Sitzungslebenszyklus, einschließlich SSO-Sitzungs-Cookies und Realm-Sitzungsrichtlinien.

Auris-Sitzung

Die Auris-Sitzung wird erstellt, nachdem die Keycloak-Authentifizierung erfolgreich ist und alle Auris-Schichtprüfungen bestanden werden (Actions-Engine, adaptives MFA, IP-Regeln, CAPTCHA). Die Auris-Sitzung ist die maßgebliche Sitzung für den Anwendungszugriff.

Beziehung

Wichtige Punkte:

• Keycloak-Sitzungen ermöglichen Single Sign-On (SSO) über Anwendungen innerhalb desselben Realms. Wenn ein Benutzer bereits in Keycloak authentifiziert ist, kann er Tokens für eine zweite Anwendung erhalten, ohne Anmeldedaten erneut eingeben zu müssen.
• Auris-Sitzungen sind pro Anwendung. Selbst wenn Keycloak-SSO aktiv ist, erhält jede Anwendung, auf die der Benutzer zugreift, ihre eigene Auris-Sitzung mit ihrer eigenen Token-Familie.
• Das Widerrufen einer Auris-Sitzung widerruft nicht die Keycloak-Sitzung (der Benutzer hat möglicherweise noch SSO-Zugriff auf andere Anwendungen). Für eine vollständige Abmeldung ruft der Logout-Flow sowohl den Auris-Sitzungswiderruf als auch den Keycloak-end_session_endpoint auf.
• In der Auris-Konsole konfigurierte Sitzungsrichtlinien (gleitender Ablauf, absoluter Ablauf) gelten für Auris-Sitzungen. Keycloak hat eigene Sitzungs-Timeout-Einstellungen auf Realm-Ebene.

Sitzungsspeicher und Performance

Auris-Sitzungen werden in PostgreSQL über Prisma gespeichert. Diese Designentscheidung hat wichtige Auswirkungen:

Dauerhaftigkeit: Sitzungen überleben Server-Neustarts und Deployments. Im Gegensatz zu In-Memory-Sitzungsspeichern (nur Redis) gehen datenbankgestützte Sitzungen bei Infrastrukturänderungen nicht verloren.

Skalierbarkeit: PostgreSQL verwaltet Millionen von Sitzungsdatensätzen effizient. Indizes für sessionToken, userId und tokenFamily gewährleisten schnelle Abfragen.

Bereinigung: Abgelaufene Sitzungen werden durch einen periodischen Cron-Job (/api/oauth/cron/cleanup) bereinigt. Dieser Job löscht abgelaufene Sitzungen und Autorisierungscodes und hält die Sitzungstabellengröße handhabbar. Der Cron läuft alle 5 Minuten über Vercel Cron.

Zugriffstoken-Validierung trifft die Datenbank nicht: Zugriffstoken sind JWTs, die lokal mit dem öffentlichen Schlüssel vom JWKS-Endpunkt verifiziert werden. Nur Refresh-Token-Austausche und Sitzungsverwaltungsoperationen erfordern Datenbankabfragen.

Verwandte Konzepte

• Tokens erklärt — JWT-Struktur, Signaturalgorithmen und Best Practices zur Speicherung
• OAuth 2.0 & OIDC — Das Autorisierungs-Framework, innerhalb dem Sitzungen operieren
• PKCE-Flow — Wie Autorisierungscodes gegen Sitzungstoken ausgetauscht werden
• Adaptives MFA & Risikobewertung — Wie die Risikobewertung die Sitzungserstellung beeinflusst
• Sicherheitseinstellungen — Sitzungsrichtlinien, Brute-Force-Schutz und IP-Regeln konfigurieren