Authentifizierung für SaaS richtig umsetzen

Authentifizierung ist kein gelöstes Problem

Die meisten Sicherheitsvorfälle bei SaaS-Anwendungen beginnen bei der Authentifizierung. Schwache Passwörter, fehlende 2FA, unsichere Token-Speicherung — die Liste der Fehler, die Teams in Produktion machen, ist lang.

Im DACH-Raum kommt hinzu: Authentifizierungsdaten sind personenbezogene Daten. E-Mail-Adressen, IP-Adressen bei Login-Versuchen, Session-Daten — alles fällt unter die DSGVO. Das schränkt die Anbieterauswahl ein und macht Self-Hosting attraktiver.

Die Methoden im Vergleich

JWT (JSON Web Tokens)

JWTs sind der De-facto-Standard für API-Authentifizierung. Der Server signiert einen Token mit User-Informationen, der Client schickt ihn bei jedem Request mit.

Vorteile: Stateless, skaliert horizontal, funktioniert über Service-Grenzen hinweg. Nachteile: Tokens können nicht einzeln invalidiert werden (ohne Blocklist). Bei Diebstahl ist der Token bis zum Ablauf gültig.

Best Practices:

• Access Token: kurze Laufzeit (15 Minuten)
• Refresh Token: längere Laufzeit (7 Tage), Rotation bei jeder Nutzung
• Tokens in httpOnly-Cookies, nicht in localStorage

Sessions (Server-Side)

Klassische Sessions speichern den Auth-State auf dem Server (in Redis oder der Datenbank). Der Client bekommt nur eine Session-ID.

Vorteile: Sofortige Invalidierung möglich, volle Kontrolle. Nachteile: Server muss State halten, horizontale Skalierung braucht Session-Store (Redis).

OAuth2 / OpenID Connect

OAuth2 ist ein Autorisierungs-Framework, OIDC baut Authentifizierung darauf auf. Essentiell für "Login mit Google/GitHub/Microsoft".

Wann nötig:

• Social Login anbieten
• Enterprise-Kunden mit eigenem Identity Provider (Azure AD, Okta)
• Single Sign-On (SSO) zwischen mehreren Anwendungen

Magic Links

Ein Link per E-Mail, der den Nutzer einloggt. Kein Passwort nötig.

Vorteile: Keine Passwort-Probleme, einfache UX, sicher (solange E-Mail sicher ist). Nachteile: Abhängig von E-Mail-Zustellung, langsamer als Passwort-Login, E-Mail-Sicherheit wird zum Single Point of Failure.

Passkeys (WebAuthn/FIDO2)

Die Zukunft der Authentifizierung. Biometrische oder Hardware-basierte Login ohne Passwort.

Vorteile: Phishing-resistent, keine Passwörter, exzellente UX auf modernen Geräten. Nachteile: Noch nicht überall unterstützt, Recovery komplex, ältere Browser ausgeschlossen.

Auth-Methoden: Pro und Contra

Auth-Provider im Vergleich

Clerk

Modernster Auth-as-a-Service. Exzellente React/Next.js-Integration, eingebaute UI-Komponenten, Multi-Tenancy.

Kosten: Kostenlos bis 10.000 MAUs. Pro ab $25/Monat. DSGVO: EU-Datenresidenz verfügbar, DPA vorhanden.

Auth0 (Okta)

Der Enterprise-Standard. Mächtig, aber komplex. Seit der Übernahme durch Okta teurer geworden.

Kosten: Free Tier bis 7.500 MAUs. Essentials ab $35/Monat. DSGVO: EU-Region wählbar, umfangreiche Compliance-Dokumentation.

Supabase Auth

Open-Source, Self-Hosting möglich. Basiert auf GoTrue. Gut integriert mit Supabase-Ökosystem.

Kosten: Kostenlos (Self-Hosted) oder im Supabase Free Tier. DSGVO: Self-Hosted = volle Kontrolle. Managed: EU-Region verfügbar.

Self-Built (Passport.js / NextAuth / Lucia)

Volle Kontrolle, kein Vendor Lock-in. Aber auch volle Verantwortung für Sicherheit.

Kosten: Nur Entwicklungszeit. Bei Subscription-Development-Teams oft die pragmatischste Option, da Auth-Expertise mitgeliefert wird. DSGVO: Maximal konform, da Daten nie das eigene System verlassen.

Der Auth-Flow im Detail

So sieht ein sicherer Auth-Flow mit JWT + Refresh Token Rotation in der Praxis aus:

Passwort-Hashing: Argon2 oder bcrypt

Falls Sie Passwörter speichern, gibt es genau zwei akzeptable Algorithmen:

Argon2id (empfohlen): Gewinner des Password Hashing Competition. Memory-Hard, resistent gegen GPU- und ASIC-Angriffe. Standard-Parameter: memory=65536, iterations=3, parallelism=4.

bcrypt: Bewährt und weit verbreitet. Work Factor mindestens 12. Limitierung: Passwörter werden bei 72 Bytes abgeschnitten.

Nie verwenden: MD5, SHA-1, SHA-256 (ohne Key Stretching), PBKDF2 (veraltet).

2FA/TOTP: Pflicht, nicht optional

Jede SaaS sollte TOTP (Time-Based One-Time Password) anbieten. Die Implementierung ist einfach (Libraries wie otplib in Node.js), der Sicherheitsgewinn enorm.

Implementierungstipps:

• Recovery Codes generieren (10 Stück, einmalig verwendbar)
• TOTP-Secret verschlüsselt in der Datenbank speichern
• Enforcement für Admin-Accounts, optional für reguläre Nutzer
• Backup: SMS als Fallback anbieten (besser als kein 2FA)

DSGVO-Anforderungen an Auth-Daten

Authentifizierungsdaten unterliegen besonderen DSGVO-Anforderungen:

• Rechtsgrundlage: Berechtigtes Interesse (Art. 6 Abs. 1 lit. f) für Session-Daten, Einwilligung für optionale Daten
• Speicherdauer: Login-Logs maximal 6 Monate, Sessions nur so lange wie nötig
• Auskunftsrecht: Nutzer müssen alle gespeicherten Auth-Daten einsehen können
• Löschung: Bei Account-Löschung alle Auth-Daten entfernen (Passwort-Hashes, Sessions, 2FA-Secrets)
• Data Breach: Kompromittierte Auth-Daten lösen die 72h-Meldepflicht aus

Fazit: Die richtige Strategie

Für die meisten SaaS-Anwendungen im DACH-Raum empfehle ich:

1. MVP/Start: Clerk oder Supabase Auth — schnell, sicher, DSGVO-konform konfigurierbar
2. Wachstum: Self-Built mit Argon2, JWT + Refresh Token Rotation, TOTP
3. Enterprise: Auth0 oder Self-Built + OIDC für SSO-Anforderungen

Passkeys als optionale Login-Methode anbieten, sobald die Nutzerbasis überwiegend moderne Browser nutzt.

Die Authentifizierung ist ein Bereich, in dem Expertise zählt. Ein einziger Fehler - Tokens in localStorage, SHA-256 statt Argon2, fehlende Rate Limits - kann die gesamte Anwendung kompromittieren.

---

Verwandte Themen

• DSGVO-konforme Analytics ohne Google
• E-Mail-Infrastruktur für SaaS im DACH-Raum
• DSGVO in der Softwareentwicklung
• API-First Development
• Node.js Backend Entwicklung