Web-Authentifizierung

KAPITEL 09 · WEB-ENTWICKLUNG

Web-Authentifizierung

Wie Webanwendungen Benutzer identifizieren und Zugriffe sichern – von Session-Cookies über JWT-Tokens bis zu OAuth 2.0, OpenID Connect und Multi-Faktor-Authentifizierung.

Sessions & Cookies JWT Tokens OAuth 2.0 MFA

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Web-Authentifizierung:

  • Definition: Was ist Authentifizierung vs. Autorisierung?
  • Session-basiert: Cookies und Server-Sessions
  • Token-basiert: JWT (JSON Web Tokens)
  • OAuth 2.0: Delegierte Autorisierung
  • OpenID Connect: Authentifizierung auf OAuth-Basis
  • SAML: Enterprise Single Sign-On
  • Passwort-Hashing: bcrypt, Argon2, scrypt
  • Multi-Faktor-Authentifizierung: TOTP, SMS, Hardware-Tokens
  • Security Best Practices: Sichere Implementierung
  • FAQ: Häufige Fragen & Antworten

1. Was ist Web-Authentifizierung?

Definition

Web-Authentifizierung ist der Prozess, bei dem eine Webanwendung die Identität eines Benutzers überprüft. Typischerweise erfolgt dies durch Eingabe von Anmeldedaten (Benutzername + Passwort), die gegen eine Datenbank oder einen Identitätsprovider validiert werden.

Nach erfolgreicher Authentifizierung erhält der Benutzer eine Session oder ein Token, das bei nachfolgenden Anfragen mitgesendet wird, um den Benutzer zu identifizieren – ohne dass er sich bei jeder Aktion erneut anmelden muss.

Wichtige Unterscheidung: Authentifizierung beantwortet die Frage "Wer bist du?", während Autorisierung die Frage "Was darfst du?" beantwortet. Beide Konzepte arbeiten zusammen, sind aber grundlegend verschieden.

Authentifizierung vs. Autorisierung

Diese beiden Begriffe werden oft verwechselt, sind aber grundlegend verschieden:

Authentifizierung

"Wer bist du?" – Überprüfung der Identität eines Benutzers.

Beispiel: Login mit Benutzername "max.mustermann" und Passwort "geheim123"
VS

Autorisierung

"Was darfst du?" – Überprüfung der Zugriffsrechte.

Beispiel: Benutzer "max" darf die Seite "/admin" nicht aufrufen (nur Admins)

Merkhilfe

Authentifizierung = Identität überprüfen (Login)
Autorisierung = Rechte überprüfen (Berechtigungen)
Reihenfolge: Erst Authentifizierung, dann Autorisierung!

2. Authentifizierungs-Methoden

Es gibt verschiedene Methoden, wie Webanwendungen Benutzer authentifizieren können. Jede hat ihre Vor- und Nachteile.

01

Session-basiert

Cookies & Server-Sessions

Der Server speichert Session-Daten und sendet eine Session-ID als Cookie an den Client.

  • Stateful (Server speichert Zustand)
  • Session-ID in Cookie gespeichert
  • Server-seitige Validierung
  • Einfach zu implementieren
  • Skalierungsprobleme bei vielen Servern
Empfohlen für: Traditionelle Webanwendungen, PHP, ASP.NET, Rails
02

Token-basiert (JWT)

JSON Web Tokens

Der Server signiert ein Token mit Benutzerdaten, das der Client bei jeder Anfrage mitsendet.

  • Stateless (kein Server-Zustand)
  • Token enthält Benutzerdaten
  • Kryptographisch signiert
  • Gut für Microservices
  • Token-Größe kann groß werden
Empfohlen für: SPAs, Mobile Apps, APIs, Microservices
03

OAuth 2.0

Delegierte Autorisierung

Ermöglicht Benutzern, sich mit externen Providern (Google, GitHub, Facebook) anzumelden.

  • "Login with Google/Facebook"
  • Keine Passwort-Speicherung nötig
  • Standardisiertes Protokoll
  • Granulare Berechtigungen (Scopes)
  • Komplexer Implementierungsaufwand
Empfohlen für: Moderne Web-Apps, SaaS, Social Login
04

SAML 2.0

Enterprise Single Sign-On

XML-basiertes Protokoll für Enterprise Single Sign-On (SSO) zwischen Organisationen.

  • Enterprise-Standard für SSO
  • XML-basierte Assertions
  • Integration mit Active Directory
  • Zentrale Identitätsverwaltung
  • Komplex und schwergewichtig
Empfohlen für: Enterprise-Umgebungen, B2B, Corporate SSO

3. OAuth 2.0 Authorization Code Flow

Der OAuth 2.0 Authorization Code Flow ist der sicherste und am häufigsten verwendete Flow für Webanwendungen.

Schritt-für-Schritt Ablauf

1
Benutzer klickt "Login with Google"

Web-App leitet Benutzer zum Authorization Server (Google) weiter

2
Benutzer authentifiziert sich bei Google

Google prüft Benutzername + Passwort (oder MFA)

3
Google fragt nach Berechtigungen (Scopes)

"Diese App möchte auf Ihre E-Mail-Adresse zugreifen"

4
Google sendet Authorization Code zurück

Code wird an Redirect-URI der Web-App gesendet

5
Web-App tauscht Code gegen Access Token

Server-zu-Server Request mit Client Secret → Access Token + ID Token

Sicherheit des Authorization Code Flow

  • Client Secret bleibt auf dem Server: Wird nie an den Browser gesendet
  • Code ist kurzlebig: Nur 10 Minuten gültig, nur einmal verwendbar
  • PKCE (Proof Key for Code Exchange): Zusätzlicher Schutz für Public Clients (SPAs, Mobile)
  • State Parameter: Schutz vor CSRF-Angriffen

4. JWT – JSON Web Token Struktur

Ein JWT besteht aus drei Teilen, die mit Punkten (.) getrennt sind: Header, Payload und Signature.

Die drei Teile eines JWT

Header

Enthält den Token-Typ (JWT) und den Signaturalgorithmus (z.B. HS256, RS256)

Payload

Enthält die Claims (Benutzerdaten, Berechtigungen, Ablaufzeit)

Signature

Kryptographische Signatur zur Validierung der Authentizität

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Wichtige JWT Claims

  • sub (Subject): Eindeutige Benutzer-ID
  • iat (Issued At): Zeitpunkt der Token-Erstellung
  • exp (Expiration): Ablaufzeitpunkt des Tokens
  • iss (Issuer): Aussteller des Tokens
  • aud (Audience): Zielgruppe des Tokens
  • scope: Berechtigungen (z.B. "read:users write:users")

5. Passwort-Hashing

Passwörter dürfen niemals im Klartext gespeichert werden! Stattdessen werden sie mit speziellen Algorithmen gehasht.

bcrypt

Der Klassiker – weit verbreitet, gut bewährt. Nutzt Blowfish-Cipher mit konfigurierbarem Work-Faktor.

Empfohlen: Cost-Faktor ≥ 12

Argon2 (Winner)

Gewinner des Password Hashing Competition 2015. Resistent gegen GPU- und ASIC-Angriffe. State-of-the-Art.

Varianten: Argon2id (empfohlen), Argon2i, Argon2d

scrypt

Speicherintensiver Algorithmus – erschwert Hardware-Angriffe durch hohen RAM-Verbrauch.

Parameter: N (CPU/Memory), r (Block), p (Parallel)

PBKDF2

Iterativer Algorithmus mit HMAC. Von NIST empfohlen, aber langsamer als moderne Alternativen.

Iterationen: ≥ 600.000 (OWASP 2023)

Niemals verwenden!

  • MD5: Komplett gebrochen, Kollisionen in Sekunden
  • SHA1: Gebrochen, nicht mehr sicher
  • SHA256 (ohne Salt): Zu schnell, anfällig für Rainbow-Tables
  • Eigene Hash-Funktionen: Immer bewährte Algorithmen verwenden

6. Multi-Faktor-Authentifizierung (MFA)

MFA kombiniert mehrere Authentifizierungsfaktoren für erhöhte Sicherheit: Wissen (Passwort), Besitz (Token), Inhärenz (Biometrie).

TOTP (Time-based)

Zeitbasierte Einmalpasswörter (6-stellig, alle 30 Sek. neu). Apps: Google Authenticator, Authy, Microsoft Authenticator.

✓ Hochsicher

SMS-Codes

Einmalpasswörter per SMS. Einfach, aber anfällig für SIM-Swapping und SS7-Angriffe.

⚠ Gering

Hardware-Tokens

Physische Security Keys (YubiKey, Google Titan). FIDO2/WebAuthn-Standard. phishing-resistent.

✓ Höchst sicher

Biometrie

Fingerabdruck, Gesichtserkennung, Iris-Scan. Bequem, aber nicht geheimhaltbar (im Gegensatz zu Passwörtern).

✓ Hochsicher

MFA-Empfehlungen

  • Für Unternehmen: Hardware-Tokens (FIDO2) oder TOTP + Passwort
  • Für Privatnutzer: TOTP-App (Authenticator) + Passwort
  • Niemals nur SMS: Zu anfällig für SIM-Swapping
  • Backup-Codes: Immer Backup-Codes für den Verlust des 2. Faktors generieren

7. Security Best Practices

Die wichtigsten Empfehlungen für eine sichere Implementierung der Authentifizierung.

Passwörter

  • Mindestens 12 Zeichen, besser Passphrases
  • Prüfung gegen bekannte Datenleaks (Have I Been Pwned API)
  • Argon2id oder bcrypt (Cost ≥ 12) verwenden
  • Immer Salt pro Passwort generieren
  • Rate Limiting bei Login-Versuchen

Tokens (JWT)

  • Kurze Lebenszeit (15-60 Minuten)
  • Refresh Tokens für längere Sessions
  • RS256 (asymmetrisch) statt HS256
  • Tokens in HttpOnly Cookies speichern
  • Niemals sensible Daten in Payload

Sessions

  • Session Timeout: 30 Minuten Inaktivität
  • Session Rotation nach Login
  • Secure + HttpOnly + SameSite=Strict
  • Session-ID: mind. 128 Bit, kryptographisch sicher
  • Logout: Session serverseitig invalidieren

HTTPS

  • Immer HTTPS – niemals HTTP für Login
  • TLS 1.2 oder 1.3 verwenden
  • HSTS (HTTP Strict Transport Security) aktivieren
  • Aktuelle Cipher Suites nutzen
  • Zertifikate regelmäßig erneuern

Monitoring

  • Alle Login-Versuche loggen (erfolgreich + fehlgeschlagen)
  • Alerts bei Brute-Force-Angriffen
  • Geo-Blocking für ungewöhnliche Länder
  • Device Fingerprinting für Anomalie-Erkennung
  • Regelmäßige Security-Audits

Fehlermeldungen

  • Generische Meldungen: "Ungültige Anmeldedaten"
  • NICHT: "Benutzer existiert nicht" oder "Falsches Passwort"
  • Keine Details über interne Fehler preisgeben
  • Account-Lockout nach X fehlgeschlagenen Versuchen
  • Benachrichtigung bei verdächtigen Logins

OWASP Top 10 – Authentifizierungs-Risiken

  • A07:2021 – Identification and Authentication Failures: Häufigste Schwachstelle
  • Schwache Passwörter, fehlendes MFA, Session-Fixation
  • Credential Stuffing, Brute-Force-Angriffe
  • Unsichere Passwort-Wiederherstellung
  • Lösung: MFA, starke Passwort-Policies, Rate Limiting, Monitoring

8. FAQ – Häufige Fragen & Antworten

Häufige Fragen zur Web-Authentifizierung

Was ist der Unterschied zwischen Session und Token?

Session-basiert: Der Server speichert die Session-Daten (z.B. in einer Datenbank oder Redis). Der Client erhält nur eine Session-ID als Cookie. Bei jeder Anfrage prüft der Server die Session-ID gegen seine Datenbank.

Token-basiert (JWT): Der Server speichert nichts. Das Token enthält alle benötigten Daten (Benutzer-ID, Berechtigungen) und ist kryptographisch signiert. Der Server validiert nur die Signatur.

Vorteile Session: Einfach zu invalidieren (Logout), weniger Daten im Cookie
Vorteile Token: Stateless, skalierbar, gut für Microservices

Warum ist JWT nicht für Sessions geeignet?

JWTs sind stateless – der Server kann sie nicht vor Ablaufzeit invalidieren. Wenn ein Benutzer sein Passwort ändert oder gesperrt wird, bleibt das JWT weiterhin gültig bis zur Ablaufzeit.

Lösungen:

  • Kurze Lebenszeit (15 Min) + Refresh Token
  • Token Blacklist (widerspricht dem Stateless-Prinzip)
  • Session-basierte Authentifizierung für Web-Apps

Fazit: JWTs sind ideal für APIs und Microservices, aber nicht optimal für traditionelle Web-Sessions.

Wie speichere ich JWTs sicher im Browser?

NICHT in localStorage/sessionStorage: Anfällig für XSS-Angriffe (JavaScript kann darauf zugreifen).

Sicher: HttpOnly Cookies

  • HttpOnly: Nicht per JavaScript lesbar (XSS-Schutz)
  • Secure: Nur über HTTPS übertragbar
  • SameSite=Strict: CSRF-Schutz

Best Practice: Access Token in HttpOnly Cookie, Refresh Token separat (oder in zweitem Cookie).

Was ist der Unterschied zwischen OAuth 2.0 und OpenID Connect?

OAuth 2.0: Nur für Autorisierung (delegierter Zugriff auf Ressourcen). Beispiel: "Diese App darf auf meine Google Drive-Dateien zugreifen".

OpenID Connect (OIDC): Erweiterung von OAuth 2.0 für Authentifizierung. Fügt ein ID Token hinzu, das Benutzerinformationen enthält.

Vereinfacht:

  • OAuth 2.0 = "Was darfst du?" (Autorisierung)
  • OIDC = "Wer bist du?" + OAuth 2.0 (Authentifizierung + Autorisierung)

Heute: Fast alle "Login with Google/Facebook" nutzen OIDC, nicht nur OAuth 2.0.

Warum ist SMS-MFA unsicher?

SMS-MFA ist anfällig für mehrere Angriffe:

  • SIM-Swapping: Angreifer übernehmen die Telefonnummer des Opfers
  • SS7-Angriffe: Schwachstelle im Telefonnetzwerk, ermöglicht Abfangen von SMS
  • Interception: SMS kann auf dem Weg zum Gerät abgefangen werden
  • Phishing: Benutzer können zur Eingabe des SMS-Codes auf einer Fake-Seite verleitet werden

Bessere Alternativen: TOTP-Apps (Google Authenticator), Hardware-Tokens (YubiKey), Push-Benachrichtigungen.

NIST-Empfehlung: SMS-MFA wird nicht mehr als sicherer 2. Faktor empfohlen.

Wie implementiere ich sicheres Passwort-Hashing?

Beispiel mit Argon2id (empfohlen):

  • Bibliothek wählen: libsodium, bcrypt (Fallback), argon2
  • Parameter: Memory ≥ 64 MB, Iterations ≥ 3, Parallelism ≥ 1
  • Salt: Immer automatisch generieren (16+ Bytes)
  • Speicherung: Hash + Salt + Parameter in Datenbank

Beispiel mit bcrypt (einfacher):

  • Cost-Faktor ≥ 12 (höher = langsamer, aber sicherer)
  • Bibliothek: bcrypt, bcryptjs (Node.js)
  • Automatische Salt-Generierung

Niemals: Eigene Hash-Funktionen, MD5, SHA1, SHA256 ohne Salt.

Was ist CSRF und wie schütze ich mich davor?

CSRF (Cross-Site Request Forgery): Angreifer verleitet den Benutzer, unbewusst eine Anfrage an eine vertrauenswürdige Website zu senden, bei der der Benutzer authentifiziert ist.

Beispiel: Benutzer ist in seiner Bank eingeloggt. Angreifer sendet Link, der eine Überweisung auslöst – Browser sendet Session-Cookie automatisch mit.

Schutzmaßnahmen:

  • SameSite Cookies: SameSite=Strict oder Lax
  • CSRF-Tokens: Einmal-Token pro Formular/Request
  • Double Submit Cookie: Token in Cookie + Request-Body
  • Origin/Referer Header: Prüfen der Herkunft
Was ist der Unterschied zwischen SAML und OAuth/OIDC?

SAML 2.0 (2002):

  • XML-basiert, schwergewichtig
  • Enterprise-Standard für SSO
  • Gut für B2B, Active Directory Integration
  • Komplex zu implementieren

OAuth 2.0 / OIDC (2012):

  • JSON-basiert, leichtgewichtig
  • Modern, für Web/Mobile/APIs
  • Besser für Consumer-Apps
  • Einfacher zu implementieren

Wann was?

  • SAML: Enterprise SSO, B2B, Active Directory, Legacy-Systeme
  • OIDC: Moderne Web-Apps, Social Login, Mobile Apps, APIs

Zusammenfassung

Die wichtigsten Punkte

  • Authentifizierung vs. Autorisierung: "Wer bist du?" vs. "Was darfst du?"
  • Session-basiert: Stateful, Server speichert Zustand, einfach zu invalidieren
  • Token-basiert (JWT): Stateless, skalierbar, gut für APIs/Microservices
  • OAuth 2.0: Delegierte Autorisierung, "Login with Google/Facebook"
  • OpenID Connect: Authentifizierung auf OAuth-Basis (ID Token)
  • SAML: Enterprise SSO, XML-basiert, Active Directory Integration
  • Passwort-Hashing: Argon2id oder bcrypt, niemals MD5/SHA1
  • MFA: TOTP oder Hardware-Tokens, niemals nur SMS
  • Security: HTTPS, HttpOnly Cookies, Rate Limiting, Monitoring

Enterprise-Tipps

  • Für Web-Apps: Session-basierte Authentifizierung mit HttpOnly Cookies
  • Für APIs: JWT mit kurzer Lebenszeit + Refresh Tokens
  • Für Enterprise SSO: SAML oder OIDC mit Identity Provider (Okta, Azure AD)
  • Für Social Login: OIDC (nicht nur OAuth 2.0)
  • Immer MFA: TOTP oder Hardware-Tokens für alle kritischen Accounts
  • Regelmäßige Audits: OWASP Top 10 prüfen, Penetrationstests durchführen

Weiterführende Themen

Web-Security

XSS, CSRF, SQL-Injection und weitere Web-Sicherheitsthemen im Detail.

Zur Web-Security
Web-APIs

REST, GraphQL, API-Design und Authentifizierung für APIs.

Zu Web-APIs
Kryptographie

Verschlüsselung, Hashing, digitale Signaturen und Zertifikate.

Zur Kryptographie
Authentifizierung & MFA

Enterprise-Authentifizierung, MFA-Strategien und Identity Management.

Zur Authentifizierung