Das Problem

Vaultwarden läuft seit Wochen stabil. SSO via Keycloak funktioniert — man kann sich einloggen, Einträge ansehen, Passwörter kopieren. Aber plötzlich: Einträge lassen sich nicht mehr editieren. Besitzer eines Eintrags kann nicht geändert werden. Kein Fehler, kein Hinweis in der UI. Die Änderung geht einfach nicht durch.

Das Frustrierende: Ein frischer Login schlägt nicht fehl. Die App sieht normal aus. Nur Schreiboperationen scheitern.

Die Diagnose

Blick in die Vaultwarden-Logs:

docker logs vaultwarden 2>&1 | grep -i "token\|warn\|error" | tail -50

Dort: fast 5000 Mal Token has expired seit dem letzten Container-Start (12 Tage). Und — mitten in den Startup-Logs — diese Warnung:

[WARN] Raise access_token lifetime to more than 5min.

Parallel dazu in Keycloak: accessTokenLifespan: 300 — also exakt 5 Minuten.

Die Ursache

Das ist kein Zufall. Bitwarden-Clients (und damit Vaultwarden) behandeln Access Tokens mit einer Laufzeit von ≤5 Minuten als bereits abgelaufen. Das ist ein hardcodierter Schwellwert im Client.

Der Ablauf der Race-Condition:

  1. Keycloak stellt Token mit 5 Min Laufzeit aus
  2. Client erkennt: “Token läuft in ≤5 Min ab” → sofortiger Refresh-Versuch
  3. Refresh Tokens sind single-use
  4. Zwei parallele Requests (z.B. Edit + Sync) nutzen denselben Refresh Token
  5. Zweiter Request schlägt fehl mit 401 Unauthorized
  6. Session ist kaputt — aber die UI zeigt das nicht direkt an

Schreiboperationen wie das Editieren eines Eintrags oder das Ändern des Besitzers senden mehrere Requests gleichzeitig. Lesevorgänge (Einträge anzeigen, Passwort kopieren) sind robuster gegenüber dieser Race-Condition. Deshalb: Lesen geht, Schreiben nicht.

Die Lösung

Zwei Optionen:

Option A: Keycloak Access Token Lifetime erhöhen

In der Keycloak Admin Console unter Realm Settings → Tokens → Access Token Lifespan von 300s auf mindestens 600s (10 Min) erhöhen. Alternativ per Client-Override nur für den Vaultwarden-Client.

Option B: Vaultwarden Sessions eigenständig verwalten lassen (gewählt)

Vaultwarden kann so konfiguriert werden, dass es Keycloak nur noch für die Authentifizierung (den Login-Vorgang) nutzt, die Session-Verwaltung aber selbst übernimmt. Dann greift die Keycloak-Token-Lifetime nicht mehr.

# Auf dem Host, wo Vaultwarden läuft
# Config-Datei liegt z.B. unter /home/<user>/vaultwarden-data/config.json

# Backup erstellen
cp /pfad/zu/vaultwarden-data/config.json \
   /pfad/zu/vaultwarden-data/config.json.bak.$(date +%Y%m%d)

# Wert ändern (jq muss installiert sein)
tmp=$(mktemp)
jq '.sso_auth_only_not_session = true' \
   /pfad/zu/vaultwarden-data/config.json > "$tmp" \
   && mv "$tmp" /pfad/zu/vaultwarden-data/config.json

# Änderung prüfen
grep sso_auth_only /pfad/zu/vaultwarden-data/config.json

Dann Container neustarten:

cd /pfad/zu/vaultwarden-compose
docker compose restart vaultwarden

Alternativ direkt über das Vaultwarden Admin Panel (/admin → SSO Settings → “Use SSO only for authentication, not for session management”). Dort greift die Änderung ohne Neustart.

Verifikation

# Startup-Logs prüfen: Die WARN-Meldung sollte verschwunden sein
docker logs vaultwarden 2>&1 | grep -i "raise access"

# Container-Status
docker ps --filter name=vaultwarden --format "{{.Status}}"

Erwartetes Ergebnis: Keine Warnung mehr, Container healthy. Dann neu einloggen (SSO) und einen Eintrag editieren — sollte wieder funktionieren.

Lessons Learned

  • 5 Minuten ist kein sicherer Wert für Keycloak Access Tokens wenn Vaultwarden/Bitwarden im Spiel ist. Entweder ≥10 Min setzen oder sso_auth_only_not_session: true.
  • Symptome irreführend: “Kann nicht editieren” klingt nach einem Permission-Problem, ist aber eine Session/Auth-Race-Condition. Ohne Log-Analyse schwer zu finden.
  • Vaultwarden loggt die Warnung beim Start — sie fällt nur unter den vielen anderen Startup-Meldungen durch. Lohnt sich, Startup-Logs einmalig auf [WARN] zu filtern.
  • Lesevorgänge sind robuster als Schreibvorgänge gegenüber Token-Problemen, weshalb die App “halb funktioniert” und das Problem lange unentdeckt bleibt.