Automatisches Session-/Token-Refresh ohne erneute Anmeldung
ID: APP-001 · Status: 🟢 aktiv · Use Case: UC-APP-001
Die App soll den Nutzer im Regelfall nie erneut zur Anmeldung auffordern. Dafür wird ein Access-/Refresh-Token-Modell mit Token-Rotation genutzt: der Access-Token ist kurzlebig, der Refresh-Token wird bei jeder Nutzung verlängert (sliding expiration), solange die App regelmäßig geöffnet wird oder Push-Interaktionen stattfinden.
Touchpoint
trading-companion-app
Grundlage
Löst sich auf Basis von AUTH-003 (Plattform-Ebene, /platform/requirements): AUTH-001 gibt seit AUTH-003 zusätzlich zum bestehenden Token einen Refresh-Token aus; POST /auth/token/refresh (AUTH-003) tauscht diesen gegen ein neues Access-/Refresh-Token-Paar. Dieser REQ (APP-001) beschreibt nur noch, WIE die App dieses bereits vorhandene Plattform- Feature nutzt – nicht mehr, OB es existiert.
Token Modell
Access Token
| Feld | Wert |
|---|---|
| Lebensdauer | 30 Minuten (gemäß AUTH-003) |
| Speicherung | Nur im Arbeitsspeicher/WebView-Kontext der App, nicht persistent |
Refresh Token
| Feld | Wert |
|---|---|
| Lebensdauer | 60 Tage, mit Rotation bei jeder Nutzung (gemäß AUTH-003) |
| Speicherung | Nativer, verschlüsselter Secure Storage (Android Keystore-gestützt, z.B. über ein Capacitor "Secure Storage"-Plugin oder EncryptedSharedPreferences) – NICHT localStorage/WebView-Storage, da das für eine App mit Push-Zugriff aus Sicherheits- und Persistenzgründen ungeeignet ist. |
Ablauf
| Feld | Wert |
|---|---|
| Beim Start | App prüft beim Start, ob ein gültiger Refresh-Token vorliegt. Falls ja: stiller Refresh-Call, neuer Access-Token (und durch Rotation ggf. neuer Refresh-Token) wird gesetzt, kein Login-Screen wird angezeigt. |
| Bei Deep Link Aus Notification | Tap auf einen Deep-Link-Button prüft/refresht den Token im Hintergrund, bevor der Zielscreen geladen wird, damit dieser sofort authentifiziert erscheint statt kurz einen Login- oder Ladefehler zu zeigen. |
| Ablauf Refresh Token | Ist der Refresh-Token abgelaufen (z.B. Gerät sehr lange nicht genutzt) oder serverseitig widerrufen: App zeigt den regulären Login-Screen. Das ist der einzige vorgesehene Fall einer erneuten Anmeldung – "nie wieder anmelden" gilt für regelmäßige Nutzung, nicht als harte Garantie. |
Sicherheit
- Refresh-Token wird nie im Klartext geloggt oder an Crash-Reports übertragen
- ANNAHME: Zusätzlicher Root/Jailbreak-Schutz des Storage ist nicht Teil der ersten Version
Abnahmekriterien
- [ ] Bei jedem App-Start mit gültigem Refresh-Token erscheint kein Login-Screen
- [ ] Der Access-Token wird automatisch im Hintergrund erneuert, bevor er abläuft
- [ ] Der Refresh-Token wird bei jeder erfolgreichen Nutzung verlängert (Rotation), sodass regelmäßige Nutzer faktisch nie erneut einloggen müssen
- [ ] Tap auf einen Deep-Link-Button aus einer Notification führt direkt zum authentifizierten Zielscreen, ohne sichtbaren Login-Zwischenstopp
- [ ] Ist der Refresh-Token abgelaufen oder ungültig, wird der Login-Screen angezeigt statt eines stillen Fehlers
- [ ] Der Refresh-Token liegt ausschließlich in nativem, verschlüsseltem Secure Storage, nicht im WebView-Storage
Depends On
- AUTH-001 (Plattform, /platform/requirements)
- AUTH-003 (Plattform, /platform/requirements)
Changelog
Eintrag 1
Version: 1.0
Changes: Initiale Version – Session-Handling-Grundanforderung für die App
Eintrag 2
Version: 1.1
Changes
Offene Annahme zum Auth-Service aufgelöst – konkret gegen AUTH-003 (neu, Plattform-Ebene) verdrahtet, das genau diesen Refresh-Mechanismus liefert