Login- und Session-Architekturen für native Mobile Apps mit IdP

Ziel und Kontext

Dieser Artikel beschreibt saubere Architektur-Varianten für Authentifizierung und Session-Handling in nativen Mobile-Apps, die einen externen Identity Provider (IdP) über OAuth 2.0 / OpenID Connect (OIDC) nutzen.
Ziel ist:
• klare Trennung der Mechanismen
  
• vergleichbare Varianten
  
• belastbare Entscheidungsgrundlage
  

Architektur-Grundlagen (präzise Begriffe)

2.1 Beteiligte Komponenten

• Mobile App (Public Client)
  
• Authorization Server / IdP
  
• Resource Server (API)
  

2.2 Token-Artefakte

• Access Token
  • kurzlebig (typisch: Minuten)
    
  • Zugriff auf APIs
• Refresh Token
  • langlebiger
    
  • dient zur Erneuerung von Access Tokens
    
  • hochsensitiv

2.3 Zwei strikt getrennte Session-Ebenen
(A) IdP-Session

• existiert im System-Browser / ASWebAuthenticationSession / Custom Tabs
  
• ermöglicht SSO
  
• nicht direkt durch App kontrolliert
  
(B) App-Session

• basiert auf lokal gespeicherten Tokens
  
• vollständig in Kontrolle der App
  
👉 Diese Trennung ist zentral für alle folgenden Varianten.

Dimensionen des Designs (orthogonal!)

Alle sinnvollen Architekturen entstehen durch Kombination dieser Dimensionen:

3.1 Dimension 1: Session-Persistenz (App-seitig)
Variante 1: Keine Persistenz

• Tokens nur im RAM
  
• nach App-Neustart verloren
Variante 2: Persistente Session
• Refresh Token im Secure Storage:
  
  • iOS: Keychain
    
  • Android: Keystore
    
• automatische Token-Erneuerung
  

3.2 Dimension 2: Session-Lifetime-Modell
Gilt für Refresh Token / Session:
Absolute Lifetime
• harte Obergrenze (z. B. 30 Tage)
Idle Timeout
• Ablauf nach Inaktivität (z. B. 15 min)
Sliding Session
• Verlängerung bei Nutzung
  
• typischerweise kombiniert mit:
  
  • Rotation
    
  • Max Lifetime
    
👉 Sliding ist kein eigenes Pattern, sondern ein Lifetime-Modell.

3.3 Dimension 3: Token-Erneuerung
Ohne Refresh Token


• Access Token läuft ab → neuer Login erforderlich
Mit Refresh Token
• Silent Refresh möglich
Mit Rotation
• jeder Refresh → neuer Refresh Token
  
• alter Token wird ungültig

3.4 Dimension 4: Zugriffsschutz auf App-Ebene
Unabhängig von IdP:

Keine zusätzliche Sperre

Lokale Re-Authentifizierung

• Biometrie (Face ID / Fingerprint)
  
• Geräte-PIN
Optionen:

• bei App-Start
  
• bei Resume
  
• bei sensiblen Aktionen (Step-up)
  

3.5 Dimension 5: Token-Sicherheitsniveau
Bearer Tokens
• Besitz reicht aus
Sender-constrained Tokens
(z. B. DPoP)
• Token an kryptografischen Schlüssel gebunden
  
• Schutz gegen Token-Diebstahl
Hardware-gebunden
• Schlüssel im Secure Enclave / TEE
  
• stärkste Bindung an Gerät
  

3.6 Dimension 6: IdP-Session-Nutzung (SSO-Verhalten)
SSO aktiv
• erneuter Login ohne User-Interaktion möglich
SSO deaktiviert / erzwungen
• z. B. prompt=login
  

Referenz-Architekturvarianten

Jetzt sinnvoll geschnittene, reale Kombinationen:
Variante A: Ephemere Session (High Security)
×

Konfiguration
• keine Persistenz
  
• kein Refresh Token
  
• kurzer Access Token
Eigenschaften
• App-Session endet beim Schliessen
  
• IdP-Session kann Login beschleunigen
Vorteile
• minimales Risiko bei Geräteverlust
  
• keine Token-Speicherung
Nachteile
• sehr schlechte UX
  
• häufige Redirects
Typisch für
• hochsensitive Spezialanwendungen
  


Variante B: Persistente Session (Standard)
×

Konfiguration
• Refresh Token im Secure Storage
  
• Bearer Tokens
  
• Absolute Lifetime
Eigenschaften
• «Stay logged in»
  
• Silent Refresh
Vorteile
• sehr gute UX
  
• Standardimplementierung
Nachteile
• Risiko bei Token-Exfiltration
  
• Revocation kritisch


Variante C: Persistente Session mit Sliding + Rotation (Best Practice)
×

Konfiguration
• Refresh Token + Rotation
  
• Sliding Session + Absolute Cap
  
• Secure Storage
Eigenschaften
• aktive Nutzung verlängert Session
  
• kompromittierte Tokens werden schnell invalidiert
Vorteile
• sehr gute Balance UX / Sicherheit
  
• heute weit verbreitet
Nachteile
• höhere Komplexität
  
• Server muss Zustand verwalten


Variante D: Persistenz + lokale Re-Authentifizierung
×

Konfiguration
• wie Variante B oder C
  
• zusätzlich
  • Biometrie / PIN vor Zugriff
Eigenschaften
• zwei Schutzebenen:
  
• Besitz (Token)
  
• Nutzerpräsenz
Vorteile
• deutlich erhöhte Sicherheit bei guter UX
  
• schützt gegen «shoulder surfing» / unlocked device
Nachteile
• UX-Friktion
  
• Fallback-Logik nötig
Typisch für
• Banking
  
• eGovernment


Variante E: Sender-Constrained Session (High Security Modern)
×

Konfiguration
• DPoP oder ähnliche Mechanismen
  
• Schlüssel im Secure Enclave / Keystore
  
• meist kombiniert mit Variante C oder D
Eigenschaften
• Token allein nicht ausreichend
  
• Bindung an Gerät
Vorteile
• sehr hoher Schutz gegen Token-Diebstahl
  
• state-of-the-art
Nachteile
• komplex
  
• Interoperabilität / Debugging anspruchsvoll

Varianten Vergleich




Variante	UX	Sicherheit	Komplexität	Bemerkung
A Ephemer	❌	✅✅	✅	selten sinnvoll
B Persistenz	✅	⚠️	⚠️	Basis
C Sliding + Rotation	✅	✅	⚠️⚠️	Best Practice
D + Re-Auth	⚠️/✅	✅✅	⚠️⚠️	für sensitive Daten
E Sender-Constrained	✅	🚀	❌	High-End

Kritische Detailthemen (oft unterschätzt)

6.1 Logout-Semantik

• Local Logout → Tokens löschen
  
• Global Logout → IdP-Session beenden (Browser!)
  
• Revocation → Refresh Token serverseitig invalidieren
  

6.2 Geräteverlust
Fragen:

• sind Tokens geschützt?
  
• ist Biometrie aktiv?
  
• gibt es Remote Revocation?
  

6.3 Offline-Verhalten

• Access Token gültig → Offline möglich?
  
• Refresh → benötigt Netzwerk
  

6.4 Multi-Device

• pro Gerät eigene Refresh Tokens?
  
• zentrale Invalidierung?
  

6.5 Step-up Authentication

• bei kritischen Aktionen erneute Authentifizierung
  
• unabhängig von Session
  



Empfehlungen

• Standard-Anwendungen → Variante C
  
• Sensitive Anwendungen (z. B. eIAM / Behörden) → Variante D + optional E
  
• Maximale Sicherheit → C + D + E kombiniert
  



Fazit

Die wesentliche Erkenntnis ist:

Es gibt nicht „das eine Login-Pattern“, sondern ein Baukastensystem aus orthogonalen Entscheidungen.

Saubere Architektur bedeutet:

• Dimensionen nicht vermischen
  
• Kombination bewusst wählen
  
• Risiken explizit adressieren
  

Empfehlung: Authentifizierungs- und Session-Architektur für eine hochsensitive Mobile-App

Zielbild

Die Anwendung soll:

• hohe Sicherheitsanforderungen erfüllen (Missbrauch bei Geräteverlust verhindern)
  
• gleichzeitig im Alltag effizient nutzbar bleiben
  
• unter unterschiedlichen Einsatzbedingungen funktionieren (wechselnde Nutzung, evtl. eingeschränkte Konnektivität)
  



Empfohlene Architektur (Kombination)

2.1 Session-Strategie
→ Persistente Session mit Sliding Lifetime und Rotation
Umsetzung
• Verwendung von Refresh Tokens
  
• Speicherung im plattformseitig geschützten Secure Storage
  
• Refresh Token Rotation bei jeder Erneuerung
  
• Kombination aus:
  
  • Idle Timeout (z. B. Stundenbereich)
    
  • Absolute Lifetime (z. B. Tagebereich)
    
Begründung
• Vermeidet häufige Logins im Einsatz
  
• Begrenzung des Schadens bei Token-Kompromittierung
  
• Standard für moderne, sichere Systeme
  

2.2 Zugriffsschutz auf App-Ebene
→ Verpflichtende lokale Re-Authentifizierung
Umsetzung
• Zugriff auf Session nur nach:
  
  • Biometrie (primär)
    
  • Geräte-PIN (Fallback)
    
• Durchsetzung:
  
  • beim App-Start
    
  • nach definierter Inaktivität (z. B. wenige Minuten)
    
  • bei sensitiven Aktionen
    
Begründung
• Schutz bei:
  
  • entsperrten, unbeaufsichtigten Geräten
    
  • gemeinsam genutzten Geräten
    
• Signifikante Erhöhung der Sicherheit ohne vollständigen Re-Login
  

2.3 Token-Sicherheitsniveau
→ Sender-constrained Tokens (empfohlen)
Umsetzung
• Bindung der Tokens an einen gerätespezifischen Schlüssel
  
• Schlüsselablage im:
  
  • Secure Enclave (iOS)
    
  • Trusted Execution Environment (Android)
    
Begründung
• Verhindert Nutzung abgegriffener Tokens auf anderen Geräten
  
• Reduziert Risiko bei Malware oder Speicherzugriff
  

2.4 IdP-Integration
→ Systembrowser-basierter Login (OIDC Best Practice)
Umsetzung
• Verwendung von:
  
  • ASWebAuthenticationSession (iOS)
    
  • Custom Tabs (Android)
    
• Nutzung vorhandener IdP-Session (SSO)
  
Begründung
• Vermeidung von Credential-Handling in der App
  
• Nutzung bestehender Authentifizierungsstärke (z. B. MFA)
  

2.5 Logout- und Revocation-Strategie
Umsetzung
• Lokaler Logout
  
  • vollständige Löschung aller Tokens
    
• Serverseitige Revocation
  
  • Invalidierung von Refresh Tokens
    
• Optional:
  
  • Global Logout über IdP
    
Begründung
• Kontrollierter Sitzungsabbruch bei:
  
  • Geräteverlust
    
  • Rollenwechsel
    
  • Sicherheitsvorfällen
    

2.6 Offline-Verhalten
Empfehlung
• Zugriff auf nicht-sensitive, bereits geladene Daten auch offline erlauben
  
• Keine Token-Erneuerung ohne Netzwerk
  
• Sensible Aktionen nur online zulassen
  

Sicherheitsniveau (Einordnung)

Die empfohlene Kombination entspricht:

• hohem Schutz gegen Geräteverlust
  
• hohem Schutz gegen Token-Diebstahl
  
• kontrollierter Session-Lebensdauer
  
• guter operativer Nutzbarkeit
  

Bewusst verworfene Alternativen

Kein vollständiger Re-Login bei jeder Nutzung
• zu hohe Friktion
  
• operativ nicht praktikabel
Keine rein persistente Session ohne Re-Auth
• unzureichender Schutz bei physischem Zugriff
Keine reinen Bearer Tokens ohne zusätzliche Sicherung
• erhöhtes Risiko bei Token-Exfiltration
  

Ergänzende Massnahmen (optional, je nach Schutzbedarf)

• Step-up Authentication bei kritischen Aktionen
  
• Gerätebindung mit Attestation
  
• Remote Session Kill
  
• Erkennung von Root/Jailbreak (mit Vorsicht einsetzen)
  

Fazit

Empfohlen wird eine mehrschichtige Sicherheitsarchitektur:

Persistente, rotierende Session
• lokale Re-Authentifizierung
  
• gerätegebundene Token
  

Diese Kombination erreicht eine robuste Balance zwischen Sicherheit und Nutzbarkeit und ist für Anwendungen mit erhöhtem Schutzbedarf geeignet.