JWT Token einfach erklärt: Authentifizierung & Sicherheit für moderne Webanwendungen

JWT Token ist eine der beliebtesten Methoden für die Authentifizierung in modernen Webanwendungen. Er wird in APIs, mobilen Apps und Diensten mit Microservice-Architektur eingesetzt, da er eine Session-lose Autorisierung ermöglicht und der Server keine Sitzungsdaten speichern muss.

Früher musste der Server jeden Nutzer mittels Sessions "merken". Mit JWT läuft alles anders: Alle nötigen Informationen werden direkt mit der Anfrage übertragen. Das macht das System schneller, besser skalierbar und ideal für verteilte Anwendungen.

In diesem Artikel erklären wir, was ein JWT Token ist, wie er funktioniert, woraus er besteht und worin die Unterschiede zu klassischen Sessions liegen.

Was ist ein JWT Token einfach erklärt?

Ein JWT Token ist eine spezielle Zeichenkette, die Informationen über einen Benutzer enthält und ihn identifiziert, ohne dass Daten auf dem Server gespeichert werden müssen. JWT steht für JSON Web Token.

Einfach gesagt: Es ist ein "digitaler Passierschein", den Sie nach dem Login erhalten. Anstatt bei jeder Anfrage die Datenbank zu befragen, schaut der Server einfach auf den Token und weiß, wer Sie sind und was Sie dürfen.

JWT wird in modernen Webanwendungen, mobilen Apps und APIs intensiv genutzt, zum Beispiel:

• beim Login auf einer Website
• bei der Authentifizierung in Apps
• bei der Nutzung eines REST-API

Das Kernprinzip: Alle wichtigen Daten stecken im Token selbst, nicht auf dem Server. Das macht das System schnell und einfach zu skalieren.

Ein JWT sieht typischerweise wie eine lange Zeichenkette mit Punkten aus, zum Beispiel:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Obwohl es wie eine zufällige Zeichenfolge aussieht, enthält es:

• Nutzerinformationen (z.B. ID, Rolle)
• Ablaufdatum
• eine Signatur zum Schutz vor Manipulation

Wichtig: JWT verschlüsselt die Daten nicht, sondern codiert sie nur. Der Inhalt ist also entschlüsselbar, kann aber ohne Verletzung der Signatur nicht geändert werden.

JWT wurde populär, weil damit Authentifizierung ohne Sessions möglich ist. Der Server muss keinen Zustand speichern - alles steckt im Token.

Wie funktioniert ein JWT Token?

Das Prinzip eines JWT Tokens ist einfach: Der Server erstellt einmalig einen Token und überprüft ihn bei jedem Request, ohne den Nutzerzustand zu speichern.

1. Der Nutzer gibt Login und Passwort ein. Diese Daten gehen an den Server und werden z.B. gegen die Datenbank geprüft.
2. Wenn die Daten stimmen, erstellt der Server ein JWT Token, das folgende Informationen enthält:
   • Nutzer-ID
   • Rolle (z. B. user oder admin)
   • Ablaufzeitpunkt (expiration time)
3. Der Token wird an den Client (Browser/App) zurückgesendet.
4. Speicherung erfolgt meist in:
   • localStorage
   • sessionStorage
   • oder als HttpOnly-Cookie (häufigste & sicherste Variante)
5. Jeder weitere Request an den Server enthält den Token, meist im Header:
   Authorization: Bearer <Token>
6. Der Server prüft:
   1. Token extrahieren
   2. Signatur prüfen
   3. Gültigkeit/Ablaufzeit prüfen
   4. Daten aus dem Payload lesen
   Ist alles korrekt, gilt der Nutzer als authentifiziert und die Anfrage wird ausgeführt.

Der Server speichert dabei keine Sitzungsdaten zwischen den Anfragen. Daher spricht man beim JWT-Ansatz auch von einem stateless Verfahren.

Ideal geeignet ist dieser Ansatz für:

• APIs
• Microservices
• verteilte Systeme

Oft wird JWT auch zusammen mit OAuth verwendet - mehr dazu im Artikel "Wie funktioniert OAuth 2.0: Login ohne Passwort und Sicherheit Ihrer Daten".

Aufbau eines JWT Tokens

Ein JWT Token besteht aus drei durch Punkte getrennten Teilen:

header.payload.signature

Jeder Teil wird Base64-codiert, sodass der Token aus scheinbar zufälligen Zeichen besteht, intern aber eine klare Struktur hat.

1. Header

Hier stehen der Typ des Tokens und der Signaturalgorithmus:

{
  "alg": "HS256",
  "typ": "JWT"
}

• alg: Signaturalgorithmus (z. B. HMAC SHA-256)
• typ: Typ des Tokens

2. Payload

Der Payload ist der Hauptteil des Tokens und enthält die eigentlichen Informationen.

{
  "userId": 123,
  "role": "admin",
  "exp": 1712345678
}

• Nutzerdaten
• Zugriffsrechte
• Ablaufzeit (exp)
• Erstellungszeit (iat)

Wichtig: Der Payload ist nicht verschlüsselt, sondern nur codiert. Jeder kann ihn einsehen.

3. Signature

Die Signatur schützt den Token vor Manipulation. Sie wird erzeugt aus:

• Header
• Payload
• geheimem Server-Schlüssel

Jede Änderung am Token macht die Signatur ungültig - der Server lehnt manipulierte Tokens ab.

Insgesamt ist ein JWT also ein eigenständiger Datencontainer mit Schutzmechanismus. Der Server muss nicht extra die Datenbank befragen, um zu wissen, wer anfragt - alles steckt im Token.

JWT Autorisierung und Authentifizierung - wo liegt der Unterschied?

Im Zusammenhang mit JWT werden die Begriffe Authentifizierung und Autorisierung häufig verwechselt.

Authentifizierung

Hier wird geprüft, wer der Nutzer ist.

• Der Nutzer gibt Login und Passwort ein
• Der Server prüft die Daten
• Stimmt alles, wird die Identität bestätigt

Erst in diesem Schritt wird der JWT Token erzeugt.

Autorisierung

Das ist der nächste Schritt: Was darf der Nutzer?

• Normale Nutzer können z. B. nur Daten lesen
• Admins dürfen auch Daten ändern

Diese Rechte stehen meist im Payload des JWT (z.B. im Feld role).

So läuft das Zusammenspiel ab:

1. Nutzer authentifiziert sich (Login)
2. Server gibt JWT Token aus
3. Im Token sind die Zugriffsrechte gespeichert
4. Bei jedem Request liest der Server die Rechte aus dem Token aus

JWT vereint also beide Prozesse: Identitätsnachweis und Rechteverwaltung.

Wichtig: Der JWT Token speichert nur das Ergebnis der Authentifizierung - die eigentliche Prüfung passiert vorher.

JWT vs. Sessions - Wo liegen die Unterschiede?

Der Mehrwert von JWT wird klar, wenn man ihn mit klassischen Sessions vergleicht.

Wie funktionieren Sessions?

• Nach dem Login speichert der Server eine Session in der Datenbank oder im Speicher
• Dem Nutzer wird eine Session ID zugewiesen (meist im Cookie)
• Bei jeder Anfrage wird die Session ID geschickt
• Der Server sucht die Session und erkennt so den Nutzer

Hier speichert der Server also den Zustand des Nutzers.

Wie funktioniert JWT?

• Der Server erstellt einen Token mit allen nötigen Informationen
• Der Token wird an den Client geschickt
• Der Client speichert den Token
• Bei jeder Anfrage wird er mitgesendet
• Der Server prüft nur den Token - keine separate Suche in der Datenbank

Zentrale Unterschiede

1. Datenhaltung
   • Session: auf dem Server
   • JWT: im Token
2. Skalierbarkeit
   • Session: aufwändiger (zentraler Speicher nötig)
   • JWT: einfach (Server sind unabhängig)
3. Performance
   • Session: Zugriff auf Speicher oder Datenbank
   • JWT: reine Signaturprüfung
4. Sicherheit
   • Session: kann auf dem Server ungültig gemacht werden
   • JWT: ist schwer zurückzuziehen, sobald ausgegeben

Wann eignet sich JWT?

• APIs und Microservices
• Mobile Apps
• Verteilte Systeme
• Login via externe Dienste

Wann sind Sessions besser?

• Einfache Websites
• Server-Side Rendering (SSR)
• Wenn striktes Session-Management nötig ist
• Wenn Zugang sofort entzogen werden muss

Fazit: JWT steht für Flexibilität und Skalierbarkeit, Sessions für Kontrolle und einfache Verwaltung.

Access Token und Refresh Token - wie funktioniert das Zusammenspiel?

In der Praxis wird JWT fast nie allein verwendet. Meist gibt es eine Kombination aus Access Token und Refresh Token - für mehr Sicherheit und Komfort.

Access Token

Das ist der eigentliche Token für API-Anfragen.

• Kurze Lebensdauer (z. B. 5-30 Minuten)
• Wird bei jeder Anfrage mitgesendet
• Enthält Nutzerdaten

Wird der Access Token gestohlen, kann er nur für kurze Zeit missbraucht werden.

Refresh Token

Ein zusätzlicher Token zum Erneuern des Access Tokens.

• Lebensdauer: Tage oder Wochen
• Wird nicht bei jeder Anfrage verwendet
• Wird besonders sicher (z. B. als HttpOnly-Cookie) gespeichert

So funktioniert das Zusammenspiel

1. Login des Nutzers
2. Server gibt
   • Access Token
   • Refresh Token
3. Nutzer macht Anfragen mit dem Access Token
4. Ist dieser abgelaufen:
   • schickt der Client den Refresh Token an den Server
   • Server prüft ihn und gibt einen neuen Access Token aus
5. Der Nutzer bleibt eingeloggt, ohne sich erneut anzumelden

Warum nicht nur ein JWT verwenden?

• Langer Token: komfortabel, aber bei Diebstahl hohes Risiko
• Kurzlebiger Token: sicher, aber unpraktisch (häufiges Ausloggen)
• Kombination löst das Dilemma: kurz für Sicherheit, lang für Komfort

Sicherheitsaspekt beim Refresh Token

• Wird meist als HttpOnly-Cookie gespeichert
• Ist nicht per JavaScript zugänglich
• Schutz vor XSS-Angriffen

Dieses Prinzip ist heute Standard in den meisten modernen Auth-Mechanismen.

Wie sicher sind JWT Tokens?

JWT ist sicher, wenn es korrekt implementiert wird. Fehler führen jedoch schnell zu Schwachstellen.

Warum kann man JWT nicht fälschen?

• Der Token wird mit einem geheimen Schlüssel signiert
• Der Client kennt diesen Schlüssel nicht
• Bei jeder Anfrage prüft der Server die Signatur neu
• Manipulierte Tokens werden abgelehnt

Hauptgefahr: Token-Diebstahl

• Man kann JWT nicht erraten, aber stehlen
• Hat ein Angreifer den Token, kann er im Namen des Nutzers Anfragen stellen
• Der Server erkennt keinen Unterschied zum echten Nutzer

Wo JWT sicher speichern?

• localStorage: einfach, aber anfällig für XSS
• sessionStorage: etwas sicherer, aber ebenfalls via JavaScript erreichbar
• HttpOnly Cookie: beste Variante, da nicht per JavaScript lesbar

Typische Fehler bei JWT

1. Zu lange Lebensdauer der Tokens - erhöht das Risiko bei Diebstahl
2. Speichern sensibler Daten (z. B. Passwörter) im Token - unbedingt vermeiden!
3. Fehlendes HTTPS - die Übertragung ist unsicher
4. Kein Widerruf-Mechanismus - daher kurze Lebensdauer und Refresh Token nutzen

Fazit zur Sicherheit

• Immer HTTPS verwenden
• Kurze Lebensdauer der Tokens
• Kombination von Access & Refresh Token
• Nur minimal notwendige Daten im Token speichern

Wann sollte man JWT einsetzen?

JWT ist ein mächtiges Werkzeug, aber nicht immer die beste Wahl. Es lohnt sich dort, wo die Vorteile wirklich zum Tragen kommen.

Wann ist JWT ideal?

1. Single Page Applications (SPA)
   • Frontend und Backend sind getrennt
   • Viele API-Requests
   • Keine klassischen Sessions

   Hier überzeugt JWT durch den stateless-Ansatz und flexible Übertragung.

2. Mobile Apps
   • Es gibt keine Cookies wie im Browser
   • Einfacher Auth-Mechanismus nötig

   JWT wird auf dem Gerät gespeichert und bei jedem Request mitgesendet.

3. APIs und Microservices
   • Viele Services, kein zentrales Session-Management

   Mit JWT können alle Services unabhängig voneinander Nutzer prüfen.

4. Login via externe Dienste
   • Zum Beispiel Login mit Google oder sozialen Netzwerken

   Hier wird JWT oft zusammen mit OAuth eingesetzt. Mehr dazu im Artikel "Wie funktioniert OAuth 2.0: Login ohne Passwort und Sicherheit Ihrer Daten".

Wann ist JWT nicht optimal?

1. Einfache Websites
   • Für kleinere Projekte oder SSR sind Sessions meist einfacher und sicherer.
2. Wenn schneller Entzug des Zugangs nötig ist
   • JWT lässt sich schwer invalidieren - Sessions sind im Vorteil.
3. Höchste Sicherheitsanforderungen
   • Banken, Unternehmen mit striktem Session-Management: Hier ist die klassische Session flexibler.

Das Wichtigste zusammengefasst

JWT ist ideal für skalierbare Systeme, APIs, Frontend-Apps und verteilte Architekturen - aber kein Allheilmittel.

Fazit

Der JWT Token ist eine moderne Methode zur Authentifizierung ohne serverseitige Sessionverwaltung. Er enthält alle nötigen Daten in sich und wird durch eine Signatur geschützt - das macht das System schnell und skalierbar.

Wir haben behandelt:

• Was ein JWT Token ist und wie er aufgebaut ist
• Wie Authentifizierung ohne Sessions funktioniert
• Die Unterschiede zwischen JWT und klassischen Sessions
• Wie Access und Refresh Token zusammenarbeiten
• Welche Risiken es gibt und wie Sie diese vermeiden

In der Praxis eignet sich JWT hervorragend für APIs, mobile Apps und Microservices, ist aber für einfache Projekte oft überdimensioniert.

Vereinfacht gesagt: JWT steht für Komfort und Skalierbarkeit, Sessions für Kontrolle und Einfachheit. Die Entscheidung hängt von Ihren Anforderungen, der Architektur und den Sicherheitsbedürfnissen ab.