So funktioniert JWT-Authentifizierung — Token statt Sitzungen

So funktioniert JWT-Authentifizierung — Token statt Sitzungen

Die interaktive FlowJam-Zeichenfläche zu dieser Erklärung — jede Bahn, jede Zeile und jeder Pfeil oben gehört zu einem echten QueryChart-Diagramm, das Sie öffnen und bearbeiten können.

So lesen Sie diese Darstellung

• Lesen Sie von links nach rechts: Anmeldung, Token-Ausstellung, Authentifizierte Anfragen.
• Die Zeile des Nutzers und die des Servers wechseln sich ab, sodass jeder Pfeil entweder den Nutzer zeigt, der etwas liefert, oder den Server, der etwas entscheidet.
• Die beiden Ablehnungskästen oben in der Anmeldespalte und in der Anfragespalte sind die Fehlerendpunkte — jede Entscheidung auf der Zeichenfläche speist einen davon.

Nachweisen, wer Sie sind

„Nutzer sendet E-Mail und Passwort“ und „Server prüft die Zugangsdaten gegen die Datenbank“ sind die einzige Stelle im Ablauf, an der ein Passwort überhaupt vorkommt. „Zugangsdaten gültig?“ teilt sich in den glücklichen Pfad und „Anmeldung abgelehnt“. Das ist herkömmliche Authentifizierung — der JWT-Teil beginnt erst, wenn die Prüfung der Zugangsdaten erfolgreich war.

Das Token ausstellen

„Server baut Header, Payload und Signatur“ ist das Herz der Darstellung. Der Header nennt den Signaturalgorithmus; der Payload trägt die Claims — die Nutzer-ID, den Ablauf und etwaige Scopes; die Signatur bindet beides so aneinander, dass das Token nicht unbemerkt verändert werden kann. „Server signiert das Token mit seinem geheimen Schlüssel“ ist der Akt, der es vertrauenswürdig macht: Nur ein Server, der den Schlüssel besitzt, kann eine gültige Signatur erzeugen. „Client empfängt das JWT und speichert es“ übergibt das Artefakt an den Client, wo es bis zum Ablauf liegt.

Zustandslose Prüfung

„Client sendet das JWT im Authorization-Header“ beginnt den sich wiederholenden Teil des Ablaufs, und „Server prüft die Signatur mit seinem geheimen Schlüssel“ ist der Grund, warum das skaliert: Eine Signatur erneut zu prüfen ist eine Berechnung, kein Datenbankzugriff, es gibt also keinen zentralen Sitzungsspeicher zu befragen. „Signatur gültig und nicht abgelaufen?“ ergänzt die Zeitprüfung und leitet ungültige oder abgelaufene Token zu „Anfrage mit 401 abgelehnt“ und gültige zu „Server vertraut den Claims und verarbeitet die Anfrage“.

Wichtige Zusammenhänge und Erkenntnisse

• Ein JWT besteht aus drei Teilen — Header, Payload, Signatur —, die durch Punkte verbunden sind; der Payload ist lesbar, Manipulationen fallen aber auf.
• Die Signatur macht aus Identität eine Berechtigung: Der Besitz eines gültigen, nicht abgelaufenen Tokens authentifiziert die Anfrage.
• Die Prüfung ist zustandslos — die erneute Berechnung der Signatur ersetzt den Blick in die Sitzungstabelle.
• Der Client muss das Token sicher speichern und mit jeder Anfrage senden, deshalb ist sein Ablauf die eigentliche Sicherheitsgrenze.
• JWT und OAuth greifen ineinander: OAuth entscheidet, was der Client tun darf, und JWT ist ein verbreitetes Format für das Token, das diese Erlaubnis trägt.

Wann Sie diese Darstellung nutzen

• Einem neuen Backend-Team erklären, warum keine Sitzungstabelle nötig ist und was die Signatur tatsächlich beweist.
• Zwischen JWT und serverseitigen Sitzungen wählen, wenn geteilter Zustand die horizontale Skalierung eines Dienstes schwierig macht.
• Die Claims eines Tokens — Ablauf, Aussteller, Zielgruppe — prüfen, bevor ein Microservice ihm vertraut.

So funktioniert es

1. Führen Sie die Claims auf, die Ihre Token wirklich tragen

   Ergänzen Sie am Schritt „Header, Payload und Signatur“ die echten Claims, die Sie ausstellen — sub, exp, iss, aud und etwaige Scopes —, damit das Diagramm Ihren Token-Vertrag dokumentiert.

2. Ergänzen Sie den Refresh-Ablauf

   Fügen Sie nach dem Ablauf den Pfad des Refresh Tokens ein: Der Client legt ein langlebiges Refresh Token vor, der Server stellt ein neues Access Token aus, und die Sitzung läuft ohne neue Anmeldung weiter.

3. Benennen Sie Ihre Strategie für den Signaturschlüssel

   Vermerken Sie am Signaturschritt Ihre Schlüsselverwaltung — ein einzelnes gemeinsames Secret (HS256) oder ein Schlüsselpaar aus öffentlichem und privatem Schlüssel (RS256) —, denn diese Wahl entscheidet, wer das Token prüfen kann.

4. Ergänzen Sie die Fehlerzweige

   Nehmen Sie abgelaufene, fehlerhaft aufgebaute und manipulierte Token als eigene Endpunkte auf, damit das Diagramm die Ablehnungen abdeckt, die Ihre API tatsächlich zurückgibt.

Häufig gestellte Fragen

Was ist ein JWT, und was steht darin?

Ein JSON Web Token ist eine Zeichenkette aus drei durch Punkte getrennten Teilen: einem Header, der den Signaturalgorithmus nennt, einem Payload mit Claims über den Nutzer und die Lebensdauer des Tokens, und einer Signatur. Header und Payload sind base64-codiertes JSON — für jeden lesbar — und die Signatur ist das, was eine Änderung ohne den Signaturschlüssel verhindert.

Warum heißt JWT-Authentifizierung zustandslos?

Weil der Server nichts über die Sitzung speichert. Jede Anfrage bringt das Token mit, und der Server prüft Signatur und Ablauf an Ort und Stelle. Es gibt keine Sitzungstabelle abzufragen und keinen Zustand über Server hinweg zu replizieren, und genau das lässt den Ansatz horizontal skalieren. Der Preis dafür: Ein Token lässt sich vor seinem Ablauf nur mit zusätzlicher Technik widerrufen.

Ist ein JWT sicher, wenn jeder den Payload lesen kann?

Lesen und Vertrauen sind zweierlei. Der Payload ist nicht verschlüsselt — schreiben Sie keine Geheimnisse hinein —, aber die Signatur sorgt dafür, dass jede Änderung das Token ungültig macht, ein Client kann seine eigenen Claims also nicht umschreiben. Für die Transportsicherheit reist das Token innerhalb von HTTPS, und die Daten, zu denen es Zugang gewährt, schützt der Ressourcenserver, indem er die Claims durchsetzt.

Wie hängen JWT und OAuth zusammen?

Sie lösen unterschiedliche Hälften des Problems. OAuth ist das Autorisierungsprotokoll — wie ein Client eine Erlaubnis und ein Token erhält. JWT ist ein Token-Format. In der Praxis sind OAuth-Access-Token oft JWTs: Der Autorisierungsserver signiert ein JWT, das die Scopes trägt, und Ressourcenserver prüfen es. Diese Zeichenfläche behandelt die Authentifizierung; die Darstellung zu OAuth behandelt die Delegation.

Diese Darstellung in QueryChart (FlowJam) bearbeiten

Öffnen Sie genau diese JWT-Zeichenfläche als eigenes Diagramm, benennen Sie Client und Server auf Ihre Dienste um, und vermerken Sie Ihre eigenen Claims.

Diese Darstellung in QueryChart (FlowJam) bearbeiten