Auswahl einer Authentifizierungsstrategie für eine neue Web-App

Für eine neue Web-App im Jahr 2026 richtet sich die Strategie nach der Architektur der Anwendung: Ein server-gerendertes Monolith sollte mit serverseitigen Sessions in einem signierten, HttpOnly-Cookie beginnen; eine SPA, ein mobiler Client oder ein API-Backend sollte kurzlebige Access Tokens mit Refresh-Token-Rotation verwenden, die in HttpOnly-Cookies gespeichert werden; alles, was Social Login oder Enterprise SSO benötigt, sollte OAuth 2.0/OIDC als zusätzliche Schicht einsetzen; und wenn Authentifizierung nicht das Kernprodukt ist, ist ein Managed Provider die defensivste Standardwahl. Passkeys sollten unabhängig von der gewählten Basis als Phishing-resistenter Faktor hinzugefügt werden. Der Rest dieses Artikels begründet jeden dieser Zweige anhand konkreter Kriterien — Widerruf, Skalierung, CSRF/XSS-Angriffsfläche, Komplexität und die UX-Fehlermuster, die erst im Produktivbetrieb auftreten.

Die Falle, in die die meisten neuen Apps tappen, ist der Griff zu JWTs, weil ein Tutorial sie verwendet hat — ohne einen stateless-Skalierungsgrund, der die Kosten des Widerrufs rechtfertigt. Dies ist eine vergleichende Entscheidung, kein Standard — daher folgen nun die Kriterien, eine Vergleichstabelle und eine Matrix, die den App-Archetyp einer Empfehlung zuordnet.

Der Rahmen, der Klarheit schafft: Wo der Zustand liegt versus wie er übertragen wird

Sessions versus Tokens ist eine Frage danach, wo der Authentifizierungszustand liegt — auf dem Server oder im Credential des Clients — während Cookies versus Authorization-Header nur entscheiden, wie dieses Credential über HTTP übertragen wird. Dies sind orthogonale Achsen, und sie als eine einzige Entscheidung zu behandeln ist der Grund, warum so viele Teams JWTs einsetzen, die sie gar nicht benötigen. Diese Unterscheidung bildet das klärende Grundgerüst für alles Folgende, und der Auth-Anbieter Authgear formuliert es auf dieselbe Weise.

Eine Session ist zustandsbehaftet: Der Server speichert den autoritativen Datensatz und übergibt dem Client eine opake ID, die darauf verweist — das Hotelkarten-Modell, bei dem die Rezeption die Masterliste führt. Ein JWT ist zustandslos: Die Claims sind selbstenthalten und signiert, sodass jeder Server sie ohne Nachschlagen verifizieren kann — das digitale Reisepass-Modell, bei dem jeder Beamte der Signatur vertraut, ohne beim Aussteller anzurufen. Beide können entweder über ein Cookie oder den Authorization-Header übertragen werden. Cookies und Header sind Transport; Sessions und Tokens sind Architektur.

Der Größenunterschied fasst den Zustandslos-versus-Zustandsbehaftet-Kompromiss in einer Zeile zusammen: Ein Session-Cookie trägt etwa 32 Bytes opaker ID und erfordert ein Server-Lookup, während ein JWT die Claims inline enthält — oft 800+ Bytes bei jedem Request — und das Lookup überspringt. Man tauscht Bandbreite und Widerruflatenz gegen die Eliminierung eines Stores.

Sessions: der Standard für server-gerenderte Apps

Für ein server-gerendertes Monolith beginnt man mit serverseitigen Sessions in einem signierten, HttpOnly-, Secure-, SameSite-Cookie — das ist die einfachste korrekte Option und bietet sofortigen Widerruf ohne Mehraufwand. Der Browser sendet das Cookie automatisch, es wird kein Auth-Zustand in JavaScript gespeichert, und das Abmelden eines Benutzers ist ein einziges Delete auf dem Server.

Die Mechanik besteht aus vier Schritten: Der Benutzer übermittelt seine Anmeldedaten, der Server erstellt einen Session-Datensatz und gibt dessen ID in einem Cookie zurück, der Browser sendet dieses Cookie bei jedem Request mit, und beim Logout werden beide Seiten vernichtet. Passwörter sollten mit Argon2 gehasht werden, bevor sie den Store berühren — das OWASP Password Storage Cheat Sheet behandelt es als den derzeit bevorzugten Algorithmus. Session-IDs sollten mit hoher Entropie generiert werden und niemals sensible Daten enthalten; das OWASP Session Management Cheat Sheet ist die kanonische Referenz für ID-Länge, Rotation und Timeout.

# FastAPI: issue an opaque session, store it server-side, set a hardened cookie
import secrets
from fastapi import FastAPI, Response
# redis client + Argon2 password verification omitted for brevity

app = FastAPI()
SESSION_TTL = 60 * 60 * 24  # 24 hours

@app.post("/login")
async def login(response: Response):  # verify Argon2 hash first
    session_id = secrets.token_urlsafe(32)          # ~256 bits of entropy
    await redis.setex(f"sess:{session_id}", SESSION_TTL, user_id)
    response.set_cookie(
        "session", session_id,
        httponly=True,    # JS cannot read it -> blunts XSS exfiltration
        secure=True,      # HTTPS only
        samesite="lax",   # mitigates CSRF on top-level navigations
        max_age=SESSION_TTL,
    )
    return {"ok": True}

Dieses Snippet zeigt den Kernpunkt von Sessions: Das Geheimnis lebt nie in JavaScript, und der Server hält die einzige Quelle der Wahrheit. Zwei Kompromisse folgen daraus. Erstens die Skalierung: Da der Datensatz serverseitig ist, benötigt ein Multi-Instanz-Deployment entweder Sticky Sessions oder — besser — einen gemeinsamen Store wie Redis, damit jede Instanz jede Session auflösen kann. Zweitens CSRF: Cookies werden bei Cross-Site-Requests automatisch gesendet, daher sollte SameSite mit einem CSRF-Token unter Verwendung von Constant-Time-Vergleich kombiniert werden, gemäß dem OWASP CSRF Cheat Sheet. Das HttpOnly-Flag schließt den XSS-Lesepfad; SameSite in Kombination mit einem Token schließt den CSRF-Pfad.

JWTs und Tokens: zustandsloses Skalieren mit Widerrufskosten

Zu rohen JWTs sollte man greifen, wenn es einen konkreten Grund für zustandsloses Skalieren gibt — eine API, die mehrere Client-Typen bedient, Microservices, die Identität untereinander weitergeben, oder domänenübergreifender Zugriff, bei dem Cookies unpraktisch sind — nicht als Standard. Der Gewinn ist real: Ein signiertes Token wird lokal gegen einen öffentlichen Schlüssel verifiziert, sodass das Store-Lookup pro Request entfällt und jeder Knoten jeden Request authentifizieren kann.

Das eigentliche Problem bei JWTs ist nicht deren Ausstellung, sondern deren Widerruf. Da das Token selbstenthalten ist, bleibt es gültig, bis es abläuft — unabhängig davon, was der Server denkt. Sofortiger Logout erfordert daher entweder kurze Token-Laufzeiten mit Refresh-Token-Rotation oder eine serverseitige Deny-List, die bei jedem Request geprüft wird — und diese Deny-List führt genau den Zustand wieder ein, den JWTs eigentlich eliminieren sollten. Das Standardmuster ist ein kurzlebiges Access Token gepaart mit einem längerlebigen, rotierten Refresh Token; die OAuth 2.0 Security Best Current Practice (RFC 9700, Januar 2025) ist der ratifizierte Anker für Refresh-Token-Rotation und kurze Access-Token-Laufzeiten — eine verlässlichere Quelle als die runden TTL-Werte, die in Blog-Posts kursieren.

Der Speicherort des Tokens bestimmt den Schadensradius. JWTs in localStorage zu speichern ist mittlerweile ein Anti-Pattern: Jedes XSS auf der Seite kann es lesen und das Token exfiltrieren — daher sollten Tokens in HttpOnly-Cookies gespeichert werden, auf die die JavaScript-Schicht keinen Zugriff hat. Speziell für Browser-Apps empfiehlt der IETF-Draft OAuth for Browser-Based Apps den Authorization Code Flow mit PKCE und warnt, dass bösartiges JavaScript weit mehr tun kann als nur ein Token zu lesen.

# FastAPI: verify an access token with PyJWT (not python-jose)
import jwt  # PyJWT
from datetime import datetime, timezone
from fastapi import HTTPException

def verify_access_token(token: str, public_key: str) -> dict:
    try:
        return jwt.decode(
            token, public_key,
            algorithms=["RS256"],          # never accept "none"; pin the alg
            options={"require": ["exp", "iat", "sub"]},
        )
    except jwt.ExpiredSignatureError:
        raise HTTPException(401, "token expired")  # client should refresh
    except jwt.InvalidTokenError:
        raise HTTPException(401, "invalid token")

# When you mint tokens, use timezone-aware UTC:
# exp = datetime.now(timezone.utc) + timedelta(minutes=15)

Zwei Versionshinweise halten dies aktuell. Es sollte PyJWT verwendet werden — FastAPIs offizielles Security-Tutorial ist zu PyJWT (import jwt) zusammen mit pwdlib migriert, und python-jose wird nur noch minimal gepflegt. Ablaufzeiten sollten mit datetime.now(timezone.utc) erstellt werden: datetime.utcnow() wurde in Python 3.12 als veraltet markiert und ist gemäß der Python-Dokumentation zu ausstehenden Entfernungen weiterhin als veraltet eingestuft, ohne dass eine Entfernungsversion festgelegt wurde — es funktioniert noch, aber der zeitzonenbewusste Aufruf ist der empfohlene Ersatz.

OAuth 2.0/2.1 und OIDC: delegierte Identität bei Bedarf

OAuth 2.0 mit OpenID Connect sollte eingesetzt werden, wenn Benutzer sich mit einem bestehenden Identity Provider anmelden sollen — „Mit Google anmelden”, GitHub, Microsoft, Okta — oder wenn Enterprise SSO benötigt wird. Dies ist das VIP-Gästelisten-Modell: Man verifiziert den Benutzer nicht selbst, sondern vertraut einem Aussteller, der ihn bereits kennt. OAuth 2.0 übernimmt die delegierte Autorisierung (Access Tokens für APIs), und OpenID Connect legt ein Identity Token darüber, sodass bekannt wird, wer der Benutzer ist.

Die Komplexität lohnt sich nur, wenn Delegation oder SSO eine echte Anforderung ist, denn der Flow bringt echte bewegliche Teile mit sich — Authorization Codes, PKCE, Scopes, Redirect URIs und JWKS-Key-Rotation. Für ein MVP mit eigenem Login und ohne Social-Anforderung ist OAuth überdimensioniert; man trägt die Redirect-Maschinerie, ohne die Delegation zu nutzen, für die sie existiert.

Wenn man OAuth einsetzt, sollte man das moderne Profil anvisieren. OAuth 2.1 ist noch ein IETF Internet-Draft (draft-15, veröffentlicht am 2. März 2026) und kein ratifizierter RFC, aber seine Richtung steht fest. Die wesentlichen Unterschiede zu OAuth 2.0 sind: PKCE ist für alle Clients, die den Authorization Code Flow verwenden, verpflichtend; Redirect URIs müssen durch exaktes String-Matching verglichen werden; und der Implicit Grant sowie der Resource Owner Password Credentials Grant werden weggelassen. Das IETF selbst weist darauf hin, dass Internet-Drafts höchstens sechs Monate gültig sind und dass es unangemessen ist, sie anders als als „work in progress” zu zitieren — OAuth 2.1 sollte daher als angestrebte Konsolidierung behandelt werden, die in der Praxis bereits von großen Identity Providern durchgesetzt wird, nicht als verabschiedeter Standard. Der Inhalt ist entscheidend: Authorization Code + PKCE für jeden Client verwenden, einschließlich vertraulicher serverseitiger Clients, und Wildcard-Redirect-URIs vermeiden.

Passkeys und WebAuthn: die Phishing-resistente Entwicklungsrichtung

Passkeys sollten als Phishing-resistenter Faktor hinzugefügt werden — nicht als Dogma. Aufgebaut auf WebAuthn/FIDO2, ist ein Passkey ein öffentlich-privates Schlüsselpaar, bei dem der private Schlüssel in der sicheren Hardware des Geräts verbleibt und eine Server-Challenge nach einer lokalen biometrischen oder PIN-Prüfung signiert. Da das Credential origin-gebunden ist und niemals übertragen wird, widersteht es Phishing, Replay-Angriffen und Credential Stuffing auf eine Weise, die Passwörter und SMS-Codes nicht können.

Die politische Lage hat sich entschieden verändert. Das NCSC gab im April 2026 bekannt, dass Passkeys nun die erste Wahl der Verbraucher für die Anmeldung bei allen digitalen Diensten sein sollten, und dass es beginnen wird, Passkeys zu empfehlen, wo immer ein Dienst sie unterstützt, und Zwei-Faktor-Authentifizierung, wo er es nicht tut — eine Verschiebung, die sich durch eine laufende Aktualisierung der Leitlinien widerspiegelt, nicht durch eine einzelne plötzliche Änderung. Die Unterstützung ist faktisch universell: Passkeys werden von den wichtigsten Betriebssystemen unterstützt, darunter Windows, ChromeOS, macOS, Android, iOS und viele Linux-Distributionen, sowie von Browsern wie Chrome, Firefox, Edge und Safari.

Die Unterstützung von Passkeys ist gelöst; die Registrierung von Passkeys ist es nicht — und das ist die eigentliche Auswahlbeschränkung. Laut Corbados Passkey Benchmark 2026 (ein Anbieter-Benchmark, keine neutrale Bevölkerungsstatistik) liegt die Web-Registrierung beim ersten Versuch bei etwa 49–83 % auf iOS, aber nur bei 25–39 % auf Windows. Die Registrierungs-UX und die Kontowiederherstellung sollten als erstklassige Designprobleme behandelt werden: Passkeys als Opt-in-Upgrade mit einem klaren Fallback anbieten und die Wiederherstellung vor dem Launch konzipieren, da ein verlorenes Gerät ohne Wiederherstellungspfad einen ausgesperrten Benutzer bedeutet.

Auth-as-a-Service: der pragmatische Standard, wenn Auth nicht das Kernprodukt ist

Wenn Authentifizierung nicht das Kernprodukt ist, ist der defensivste Standard für 2026 ein Managed Provider — Auth0, Clerk, Supabase Auth, WorkOS oder Stytch — denn man erbt Sessions, Social Login, MFA und Passkeys, ohne selbst die Angriffsfläche oder die Wartung verantworten zu müssen. Diese Anbieter liefern Drop-in-SDKs, die den gesamten Lebenszyklus abdecken, einschließlich der OAuth-Redirect-Maschinerie und der WebAuthn-Abläufe, die man sonst selbst bauen und debuggen müsste.

Die Entscheidung ist wirtschaftlich eindeutig. Eine eigene Implementierung gibt Kontrolle und keine Kosten pro MAU; ein Managed Provider liefert eine gehärtete Implementierung, schnellere Time-to-Login und die Bereitschaft eines anderen für den sicherheitskritischen Pfad. Für die meisten Greenfield-Apps, bei denen Login eine Grundvoraussetzung und kein Differenzierungsmerkmal ist, ist der Managed-Weg der rationale Ausgangspunkt — und man kann später davon migrieren, wenn Skalierung oder Kosten es erfordern.

Eine Entscheidungsmatrix für Authentifizierungsmethoden

Die Strategie folgt dem App-Archetyp. Den eigenen Anwendungsfall der entsprechenden Zeile zuordnen, dort beginnen und Passkeys als Phishing-resistenten Faktor überall hinzufügen.

Die verbreitete Produktionsarchitektur ist ein Hybrid: Sessions für die server-gerenderte Web-App, JWTs für die API, die von SPAs und Mobile-Clients genutzt wird, OIDC für Social Sign-in und Passkeys als Opt-in-Upgrade. Der zugrundeliegende Branchentrend ist, das Passwort seltener, an weniger Stellen, mit mehr Scope und Nachvollziehbarkeit zu übertragen — genau deshalb haben Scoped Tokens die passwortbasierte Git-Authentifizierung ersetzt und warum Passkeys Passwörter nun vollständig ablösen.

Was Session Replay über UX-Fehlermuster bei der Authentifizierung verrät

Session Replay ist eine Technik, die den realen clientseitigen Ablauf rekonstruiert, und das Wiedergeben von Authentifizierungsabläufen bringt einen erkennbaren Katalog von Fehlermustern ans Licht, die Backend-Logs verpassen — denn die richtige Strategie auf dem Papier garantiert nicht, dass Benutzer sich tatsächlich anmelden können (dies sind Fähigkeiten der Technik, keine gemessenen Vorfallraten):

• Stille Token-Ablauf-Logout-Schleifen. Wenn ein Refresh Token mitten in einer Session abläuft, kann eine SPA den Benutzer wiederholt zur Anmeldung weiterleiten. Replay zeigt die Redirect-Schleife in der Timeline, die Fehler-Logs verpassen, weil jeder einzelne Request technisch gesehen einen validen 401 zurückgibt.
• Abgebrochene Passkey-Registrierung. Replay zeigt, wo Benutzer den WebAuthn-Ablauf abbrechen — der OS-Prompt erscheint und der Benutzer bricht ab — was genau das Fehlermuster ist, das die niedrigen Windows-Registrierungszahlen vorhersagen.
• OAuth-Redirect-Sackgassen. Ein Post-Consent-Redirect, der auf einer leeren oder Fehlerseite landet (nicht übereinstimmende Redirect URI, verlorener state-Parameter), ist in den Backend-Logs unsichtbar, weil der Roundtrip außerhalb des eigenen Servers stattfindet; Replay erfasst die Sackgasse so, wie der Benutzer sie erlebt hat.
• Browserspezifische Cookie-Fehler. SameSite- und Secure-Cookie-Probleme, die sich lokal nicht reproduzieren lassen, treten zutage, wenn Replay die fehlschlagende Session mit einem bestimmten Browser und einer bestimmten Version korreliert.

Der Kernpunkt ist, dass Authentifizierung eine UX-Oberfläche ist, nicht nur eine Protokollwahl — und die gewählte Strategie bestimmt, welche dieser Fehlerklassen man debuggen wird.

Die Basis wählen, die zur Architektur der App passt, den Credential-Speicher härten (HttpOnly-Cookies, niemals localStorage) und Passkeys als Opt-in-Phishing-resistenten Faktor hinzufügen. Für die meisten neuen Apps ist der ehrliche erste Schritt ein Managed Provider oder ein Sessions-first-Monolith; zu rohen JWTs sollte man nur greifen, wenn eine echte Anforderung an zustandsloses Skalieren die Widerrufskosten rechtfertigt. Sobald der Login in Betrieb ist, sollte der reale Ablauf beobachtet werden — die Lücke zwischen einer soliden Strategie und einer funktionierenden liegt genau in den UX-Details, die erst im Produktivbetrieb sichtbar werden.

FAQs

Sollte ich JWTs standardmäßig für eine neue Web-App verwenden?

Nein. Rohe JWTs sollten nur eingesetzt werden, wenn es einen konkreten Grund für zustandsloses Skalieren gibt, etwa eine API, die mehrere Client-Typen bedient, oder Microservices, die Identität untereinander weitergeben. Für ein server-gerendertes Monolith sind serverseitige Sessions einfacher und bieten sofortigen Widerruf. JWTs sind selbstenthalten, sodass ihr Widerruf vor Ablauf entweder kurze Token-Laufzeiten mit Refresh-Token-Rotation oder eine serverseitige Deny-List erfordert — was genau den Serverzustand wieder einführt, den JWTs eigentlich eliminieren sollten.

Ist ein Session-Token dasselbe wie ein JWT?

Nein. Ein Session-Token ist eine opake ID von etwa 32 Bytes, die auf den auf dem Server gespeicherten Authentifizierungszustand verweist, sodass jeder Request ein Lookup erfordert. Ein JWT trägt seine Claims inline und wird lokal gegen eine Signatur verifiziert, ohne Lookup — oft mit 800 oder mehr Bytes pro Request. Die beiden repräsentieren den Zustandslos-versus-Zustandsbehaftet-Kompromiss: Eine Session hält den Zustand auf dem Server, während ein JWT ihn in das signierte Credential des Clients verlagert.

Kann ich ein JWT in localStorage speichern, wenn ich meine Eingaben bereinige?

Nein, JWTs in localStorage zu speichern ist ein Anti-Pattern, unabhängig von der Eingabebereinigung, weil jede Cross-Site-Scripting-Schwachstelle irgendwo auf der Seite localStorage lesen und das Token exfiltrieren kann. Credentials sollten in HttpOnly-Cookies gespeichert werden, auf die JavaScript keinen Zugriff hat, kombiniert mit SameSite und einem CSRF-Token. Für Browser-Apps empfiehlt der IETF-Draft OAuth for Browser-Based Apps den Authorization Code Flow mit PKCE anstelle von client-lesbarem Token-Speicher.

Ist OAuth für ein MVP mit eigenem Login überdimensioniert?

Ja, wenn das MVP nur eigenen Login ohne Social Sign-in oder Enterprise SSO benötigt, fügt OAuth 2.0 Maschinerie hinzu, die nicht genutzt wird. Der Flow bringt Authorization Codes, PKCE, Scopes, Redirect URIs und JWKS-Key-Rotation mit — alles, was existiert, um delegierte Identität zu unterstützen. OAuth mit OpenID Connect sollte nur eingesetzt werden, wenn 'Mit Google anmelden', GitHub oder Enterprise SSO eine echte Anforderung ist; andernfalls sollte man mit Sessions oder einem Managed Provider beginnen.