Ja, wenn richtig implementiert. Das größte Problem ist Token-Revocation.

Kann ein Hacker einen JWT fälschen?

Nein, wenn das Secret sicher ist. Aber wenn das Secret geleakt wird, ja.

Sollte ich Sessions verwenden?

Für einfache Apps ja. Für große Systeme JWT oder OAuth.

IT-Sicherheit

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

Nico FreitagIT-SicherheitPublished on 2026-03-17

Authentifizierung ist wie ein User beweist, wer er ist. Es ist fundamental für Sicherheit. Aber es gibt viele Wege das zu tun – Sessions, JWT, OAuth – und sie funktionieren alle anders.

Sessions (Die alte Art)

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)

JWT (JSON Web Tokens)

Wie es funktioniert: 1. User loggt sich ein 2. Server erstellt einen Token (digital signed): ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjo0MiwiZXhwIjoxNjM2NTAwMDAwfQ.xyz123 ``` 3. Der Token wird zum Client gesendet 4. Bei jedem Request sendet der Client den Token: ``` Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... ``` 5. Server dekodiert den Token und überprüft die Signatur ``` Token = Header.Payload.Signature Header: {"alg": "HS256", "typ": "JWT"} Payload: {"user_id": 42, "exp": 1636500000} Signature: HMAC(header.payload, secret_key) ``` Vorteile: - Stateless (keine DB auf dem Server nötig) - Scalable (jeder Server kann den Token validieren) - Standard-Format Nachteile: - Token kann nicht revoken werden (bis Expiration) - Wenn Secret geleakt wird, sind alle Tokens kompromittiert - Größer als Session IDs

OAuth 2.0

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

Vergleich

| Feature | Sessions | JWT | OAuth 2.0 | |---------|----------|-----|-----------| | Stateless | Nein | Ja | Ja | | Revokable | Ja | Nein | Ja (aber kompliziert) | | Scalable | Nein | Ja | Ja | | Einfach | Ja | Mittel | Nein | | Passwort sicher | Ja | Ja | Ja (external) |

Was sollte ich nutzen?

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.

Security Best Practices

1. Immer HTTPS: Alle Authentication ist sinnlos ohne Encryption 2. Immer Hash Passwörter: Mit bcrypt, nicht SHA1 oder MD5 3. Immer Expiration: Tokens sollten ablaufen 4. Immer Rotation: Refresh Tokens erneuern Access Tokens 5. Immer Secure Cookies: HttpOnly + Secure Flags

Conclusion

Es gibt nicht "die beste" Authentication-Methode – es kommt auf deine Architektur an. Aber: Egal welche du wählst, nutze sichere Praktiken.

Our Service

IT Security

About the Author

Nico Freitag

Founder & Geschäftsführer

Nico Freitag is the founder and CEO of AXIS/PORT. With expertise in AI consulting, software development, and IT security, he helps businesses with their digital transformation.

FAQ