Die moderne Authentifizierung: Passkeys, OIDC, Sessions - die echte kurze Liste

Ein beliebter HN-Thread stellt die Frage wieder in den Raum: Wie sollte man eine App im Jahr 2026 authentifizieren? Die Antwort lautet nicht mehr „JWT + Refresh-Token“. Ein überarbeiteter Überblick.

In einfachen Worten

En 2026 hängt die „richtige“ Art und Weise, eine Webanwendung zu authentifizieren, von zwei Fragen ab: (1) Sind Sie eine B2C-App für die breite Öffentlichkeit oder ein B2B-SaaS? (2) Sind Sie bereit, Ihren eigenen IdP zu betreiben, oder verlassen Sie sich auf einen Anbieter? Die Muster der Mitte der 2020er Jahre (JWT stateless + Refresh in localStorage) sind veraltet - und das aus gutem Grund.

Der Fall

Der HN-Thread greift die klassische Diskussion auf und kommt zu einem interessanten Konsens: Für die meisten Anwendungen ist der pragmatische Stack 2026:

1. Serverseitige verschlüsselte Session in HttpOnly-Cookie + SameSite=Lax für den Authentifizierungszustand. Keine JWTs mehr auf der Client-Seite.
2. OIDC (Google/Apple/GitHub) für die passwortlose Onboarding.
3. Passkeys (WebAuthn) für die zweite Stufe oder als vollständiger Ersatz für das Passwort. Endlich überall angenommen (iOS 17+, Android 13+, alle Browser).
4. Kurze Rotation der serverseitigen Session (~1h) + langer Refresh (~14 Tage) über separates Cookie.
5. Keine JWTs auf der Client-Seite, es sei denn, Sie haben echten stateless multi-tenant zu erledigen.

Was sich strukturell geändert hat, sind drei Dinge. Eins: Das Ende von localStorage für sensible Tokens (XSS = totale Kompromittierung, es gibt keinen Streit mehr). Zwei: Die Reife der Passkeys - die öffentliche Akzeptanz überschreitet jetzt die kritische Schwelle in den wichtigsten Ökosystemen (Google, Apple, Microsoft haben alle eingesetzt), auch wenn keiner von ihnen eine detaillierte aktuelle Zahl veröffentlicht hat. Drei: Gehostete IdPs (Clerk, WorkOS, Auth0) bieten jetzt eine SSO/SCIM/passkeys-All-in-One-Abdeckung, die kein Team mit weniger als 5 Personen wieder implementieren sollte.

Under the hood

• Cookie-Session: Secure; HttpOnly; SameSite=Lax; __Host- Präfix. Rotation bei jeder Privilegieneskalation.
• CSRF: SameSite=Lax deckt 95% der Fälle ab; das Hinzufügen eines CSRF-Tokens zu sensiblen Mutationen bleibt der Gurt.
• PKCE ist auf allen öffentlichen OAuth-Flows (SPA, Mobile) obligatorisch.
• Häufige Falle: Passkeys zu früh als "obligatorische" 2FA zu setzen - Kontenverlust, wenn der Benutzer nur ein Gerät hat.
• Beliebte Schwachstelle: Browser-Erweiterungen, die den Speicher einer SPA lesen - ein weiteres Argument dafür, nichts in localStorage zu speichern.

So what

Drei Erkenntnisse. Eins: Wenn Sie 2026 starten, nehmen Sie einen Anbieter (Clerk, WorkOS, Stack Auth), es sei denn, es gibt einen bestimmten regulatorischen Grund. Die eingesparte Ingenieurszeit geht ins Produkt. Zwei: Wenn Sie einen vererbten JWT-in-localStorage-Stack haben, planen Sie die Migration zu Session-Cookies - das ist eine prioritäre Sicherheitsarbeit, keine kosmetische. Drei: Passkeys sind bereit; jetzt als Option aktivieren und bis 2027 im Unternehmen durchsetzen. Zu beobachten: Die Standardisierung von Passkeys zwischen Plattformen (das echte B2B-Hindernis).