Authentication erklärt – JWT vs. OAuth2 vs. Sessions

Wie es funktioniert: 1. User loggt sich ein mit Username + Password 2. Server erstellt eine Session und speichert sie in einer Datenbank 3. Ein Session-ID wird im Cookie gesendet: `Set-Cookie: session_id=abc123` 4. Bei jedem Request sendet der Browser das Cookie mit 5. Server überprüft die Session-ID in der Datenbank ``` Browser: GET /api/profile Cookie: session_id=abc123 Server: SELECT * FROM sessions WHERE id = 'abc123' -> Session gefunden, User ist User #42 -> Return User #42's Daten ``` Vorteile: - Einfach - Server kann eine Session jederzeit revoken Nachteile: - Stateful (brauchst eine DB auf dem Server) - Nicht scalable für viele Server - CSRF anfällig (wenn nicht richtig gemacht)

Wie es funktioniert: 1. User klickt "Login with Google" 2. App redirects zu Google's Login-Seite 3. User loggt sich bei Google ein 4. Google sendet einen Authorization Code zurück 5. App sendet den Code + Secret zu Google (Backend-to-Backend) 6. Google sendet einen Access Token zurück 7. App nutzt den Token um User-Daten von Google zu bekommen ``` User: "Login with Google" | v (1) Browser -> App | v (2) Google Login Page | User enters credentials | v (3) Google -> App Code: abc123 | (4) App Backend -> Google Backend exchange Code for Token | Google -> App Access Token: xyz789 ``` Vorteile: - Kein Passwort teilen mit der App - Delegiert Authentication zu Google, Facebook, etc. - Secure by Design - Standard (viele OAuth-Provider) Nachteile: - Abhängig von External Provider - Komplexer zu implementieren - Keine Kontrolle über den Login-Flow

Nutze Sessions wenn: - Du eine einfache Web-App hast - Du Logins revoken brauchst - Du auf einem oder wenigen Servern hostest Nutze JWT wenn: - Du eine Microservice-Architektur hast - Du viele Server/Regions hast - Stateless Authentication ist wichtig Nutze OAuth wenn: - Du Third-Party Login willst - Du Sicherheit delegieren willst - User sind es gewöhnt, mit "Login with Google" zu rechnen Best Practice kombiniert: Nutze OAuth2 für Third-Party, aber behalte ein lokales Auth-System für Fallbacks.