Authentifizierung

Bild: Christoph Probst at de.wikipedia, Public domain, Wikimedia Commons

Kurz: Der Vorgang, bei dem ein Nutzer oder System beweist, dass es wirklich die Identität ist, die es vorgibt zu sein — z. B. durch Passwort, Zertifikat oder biometrisches Merkmal.

Genauer: Authentifizierung (“Wer bist du?”) ist von Autorisierung (“Was darfst du?”) zu unterscheiden — die beiden werden oft verwechselt, sind aber unabhängige Schritte: erst wird die Identität geprüft, dann wird anhand dieser Identität entschieden, welche Rechte gelten. Eine Session hält den Zustand “bereits authentifiziert” für nachfolgende Anfragen, damit der Nutzer sich nicht bei jeder einzelnen Aktion neu ausweisen muss.

Im Detail

Der klassische Ablauf

Ein typischer Authentifizierungsablauf bei einer Webanwendung läuft in mehreren Schritten ab:

1. Nutzer sendet Zugangsdaten (z. B. E-Mail + Passwort)
2. Server prüft: stimmt der gehashte Wert des eingegebenen Passworts
   mit dem gespeicherten Hash überein? (siehe Hashing)
3. Bei Erfolg: Server erstellt eine Session oder ein signiertes Token (z. B. JWT)
4. Client speichert Session-Cookie/Token
5. Bei jeder weiteren Anfrage: Client schickt Cookie/Token mit,
   Server prüft dessen Gültigkeit statt erneut Zugangsdaten zu verlangen

Wichtig: Passwörter werden serverseitig nie im Klartext gespeichert, sondern nur als Hash (idealerweise mit einem zusätzlichen, pro Nutzer zufälligen “Salt”, um sogenannte Rainbow-Table-Angriffe zu verhindern, bei denen ein Angreifer vorab berechnete Hash-Tabellen für gängige Passwörter nutzt).

Session-basiert vs. Token-basiert

Es gibt zwei grundlegend unterschiedliche Architekturen, den authentifizierten Zustand zu verwalten. Bei Session-basierter Authentifizierung speichert der Server einen Sitzungszustand (z. B. in einer Datenbank oder Redis), der Client hält nur eine zufällige, bedeutungslose Session-ID als Cookie — der Server muss bei jeder Anfrage nachschlagen, ob diese ID gültig ist. Bei Token-basierter Authentifizierung (z. B. JWT, JSON Web Token) enthält das Token selbst alle relevanten Informationen (Nutzer-ID, Rechte, Ablaufzeit), kryptografisch signiert — der Server muss nichts speichern, sondern prüft nur die Signatur. Der Vorteil von Tokens ist Skalierbarkeit (kein zentraler Sitzungsspeicher nötig, ideal für verteilte Systeme); der Nachteil: Ein einmal ausgestelltes JWT lässt sich vor Ablauf nicht ohne Weiteres “zurückrufen”, weil der Server ja gar nicht nachschaut, ob es noch gültig sein soll.

Delegierte Authentifizierung: OAuth und OpenID Connect

Neben dem klassischen Passwort-Verfahren gibt es zunehmend passwortlose oder delegierte Ansätze: Magic Links (ein Einmal-Link wird per E-Mail verschickt), OAuth 2.0/OpenID Connect (Authentifizierung wird an einen Drittanbieter wie Google oder GitHub delegiert) und WebAuthn/Passkeys (kryptografische Schlüsselpaare statt Passwörter, direkt im Gerät gespeichert). Bei OAuth/OpenID Connect meldet sich der Nutzer beim Drittanbieter an, dieser bestätigt der eigenen Anwendung kryptografisch signiert die Identität — die eigene Anwendung sieht das Passwort des Nutzers nie, was sowohl die eigene Angriffsfläche reduziert als auch dem Nutzer erspart, sich ein weiteres Passwort zu merken. Diese Verfahren vermeiden das grundlegende Problem klassischer Passwörter: Menschen wählen sie oft schwach oder wiederverwenden sie über mehrere Dienste hinweg — ein Passwort-Leck bei Dienst A gefährdet dann auch Dienst B.

Typische Schwachstellen

Häufige Implementierungsfehler bei Authentifizierung: Zu kurze oder unrandomisierte Session-IDs (erraten/erzwungen), fehlende Regeneration der Session-ID nach dem Login (Session-Fixation-Angriff, bei dem ein Angreifer eine Session-ID vorgibt, bevor sich das Opfer einloggt, und danach dieselbe ID nutzt, um sich als angemeldet auszugeben), und fehlendes Rate-Limiting beim Login (ermöglicht Brute-Force-Angriffe, bei denen ein Angreifer automatisiert tausende Passwörter durchprobiert). Timing-Angriffe sind eine subtilere Gefahr: Vergleicht der Server das eingegebene Passwort naiv Zeichen für Zeichen mit dem gespeicherten Wert, kann ein Angreifer aus winzigen Zeitunterschieden in der Serverantwort ableiten, wie viele Zeichen bereits korrekt geraten wurden — konstant-zeitige Vergleichsfunktionen verhindern das.

Siehe auch: 2FA, Session, Authentizität