Was ist JWT? So funktioniert die Authentifizierung mit JSON Web Token

Was ist JWT und wofür braucht man es?

JWT (JSON Web Token) ist ein offener Standard, der Aussagen über einen Nutzer oder ein System als kompakte, URL taugliche und signierte Zeichenkette zwischen zwei Parteien transportiert. Der Server prüft die Signatur und erkennt also, ob jemand den Inhalt unterwegs verändert hat. Die IETF beschreibt das Format in RFC 7519.

Stellen Sie sich einen versiegelten Eintrittsausweis vor. Darauf stehen Ihr Name, Ihre Berechtigungen und ein Ablaufzeitpunkt. Daher muss der Pförtner Sie nicht persönlich kennen. Ist das Siegel echt, lässt er Sie ein, und wenn jemand den Ausweis manipuliert hat, ist das Siegel gebrochen.

Deshalb setzen Teams JWT in Systemen ein, in denen mehrere Teile miteinander sprechen, zum Beispiel Weboberfläche, Mobile App und API. Nach der Anmeldung beantwortet das Token bei jeder weiteren Anfrage die Frage „Wer bin ich, und was darf ich?“. Somit kann der Server die Antwort prüfen, ohne jedes Mal in die Datenbank zu schauen.

Allerdings ist JWT keine Sicherheitsabkürzung. Richtig aufgesetzt, ist es ein praktisches Transportformat. Sonst erzeugt es leise Schwachstellen. In dieser Anleitung gehen wir Aufbau, Ablauf, Risiken und Checkliste auf konzeptioneller Ebene durch.

Wer fragt, was ist JWT, gehört meist zu einer von zwei Gruppen. Erstens gibt es Einsteiger, die das Wort „Token“ verstehen wollen. Zweitens gibt es technische Teams, die ein bestehendes System prüfen. Wir beginnen deshalb mit einer einfachen Definition und gehen danach in die Tiefe.

Was ist JWT, einfach erklärt mit einem Alltagsbeispiel?

Denken Sie zunächst an einen versiegelten, durchsichtigen Umschlag. Jeder kann den Brief darin lesen, denn der Umschlag ist klar. Das Siegel gehört aber nur der Stelle, die ihn ausgestellt hat, und niemand kann es nachmachen. Ändert jemand den Brief, bricht das Siegel, und Sie merken es sofort.

Ebenso funktioniert ein JWT. Jeder, der es besitzt, kann den Inhalt lesen, also ist der Inhalt nicht geheim. Geheim ist stattdessen der Schlüssel, der die Signatur erzeugt. Dieser Unterschied ist wichtig, denn der häufigste Anfängerfehler ist die Annahme, ein JWT sei verschlüsselt.

Zum Beispiel enthält eine Eintrittskarte Angaben über Sie, und das Personal prüft sie am Eingang. Es kann die Karte bestätigen, indem es mit der Kartennummer in der Zentrale nachfragt. Andererseits kann es auch das Siegel ansehen. Die erste Methode ähnelt einem Session Cookie, die zweite dem JWT Ansatz.

Was ist JWT in der Praxis, und wo setzen Sie es ein?

Beispielszenario: Ein Handelsunternehmen betreibt eine Mobile App, einen Webshop und ein Lagerpanel, alle mit demselben Nutzerkonto. Meldet sich ein Kunde einmal an, dann stellt ein Identitätsdienst ein signiertes Token aus. Der Bestelldienst prüft dieses Token dann, ohne den Identitätsdienst zu fragen. Folglich hängen die Dienste weniger voneinander ab, und das System wächst leichter.

• Single Sign on (SSO): Ein Nutzer meldet sich einmal an und wechselt zwischen mehreren Anwendungen.
• API Zugriff: Web und Mobile Clients hängen bei jeder Anfrage ein Token an.
• Identität zwischen Diensten: Microservices sagen sich per Token, wer sie sind.
• Kurzlebige Einzelaktionen: Zum Beispiel die Gültigkeitsangabe eines Bestätigungslinks.

Kurz gesagt lautet die praktische Antwort auf die Frage, was ist JWT: der Standardweg, Identität und Berechtigung sicher zwischen zwei Parteien zu transportieren. Trotzdem passt JWT nicht in jeden Fall, wie die späteren Abschnitte zeigen.

Woraus bestehen Header, Payload und Signatur eines JWT?

Zunächst hat ein JWT drei Teile, und Punkte trennen sie. Konzeptionell sieht die Form so aus: „Header.Payload.Signatur“. Das System schreibt jeden Teil in base64url, einer URL tauglichen Kodierung. Kodierung ist keine Verschlüsselung, deshalb kann jeder sie wieder in lesbaren Text zurückwandeln.

• Header: Ein kleines JSON Objekt, das den Tokentyp und den Signaturalgorithmus nennt.
• Payload: Ein JSON Objekt mit den Claims, also den Angaben zum Subjekt und zur Nutzung des Tokens.
• Signatur: Ein Wert, der die Unversehrtheit belegt und aus Header und Payload mit einem Schlüssel entsteht.

Danach berechnet der Server die Signatur neu und vergleicht sie mit der empfangenen. Passt sie nicht, hat jemand Header oder Payload verändert, und der Server lehnt das Token ab. Konkret beruht die gesamte Sicherheit auf diesem Vergleich. Somit bringt ein System ohne Signaturprüfung keinen Nutzen aus JWT.

Außerdem ist der im Header genannte Algorithmus allein keine Vertrauensquelle. Dazu kommen wir in den Sicherheitsabschnitten.

Hinweis: Wir zeigen in diesem Artikel bewusst kein echt aussehendes Token. Für das Verständnis genügt das dreiteilige Schema.

Was sind Claims in der JWT Payload?

Anders gesagt ist ein Claim eine einzelne Aussage über das Token oder sein Subjekt. RFC 7519 definiert einige Standardnamen (registrierte Claims). Alle sind optional, doch die meisten Systeme nutzen mehrere davon. Dadurch meinen verschiedene Anwendungen mit demselben Wort dasselbe.

• iss (issuer): Nennt den Aussteller des Tokens.
• sub (subject): Nennt, um wen es geht, meist die Nutzerkennung.
• aud (audience): Nennt den Dienst, für den das Token gedacht ist.
• exp (expiration time): Nennt den Zeitpunkt, ab dem das Token nicht mehr gilt.
• nbf (not before): Nennt den Zeitpunkt, vor dem niemand das Token annehmen soll.
• iat (issued at): Nennt den Zeitpunkt der Ausstellung.
• jti (JWT ID): Gibt dem Token eine eindeutige Kennung, die bei der Erkennung von Wiederverwendung hilft.

Sie können außerdem eigene Claims ergänzen, etwa eine Nutzerrolle. Halten Sie die Payload aber klein, denn das Token reist bei jeder Anfrage mit. Zudem gehören keine sensiblen Daten in eigene Claims, und der Abschnitt über sensible Daten erklärt warum.

Wie funktioniert die JWT Signatur, und warum prüfen Sie sie bei jeder Anfrage?

Es gibt zwei Hauptwege zum Signieren. Erstens nutzt man ein gemeinsames Geheimnis mit einem Nachrichtenauthentifizierungscode (zum Beispiel HMAC). Aussteller und Prüfer kennen dann dasselbe Geheimnis. Zweitens gibt es die asymmetrische Signatur: Der Aussteller signiert mit einem privaten Schlüssel, und Prüfer nutzen nur den öffentlichen Schlüssel.

Zum Beispiel kann in einer kleinen App mit nur einem Dienst ein gemeinsames Geheimnis genügen. Bei mehreren Diensten ist die asymmetrische Signatur bequemer, weil die prüfenden Dienste keine Signaturen erzeugen können. Folglich kann ein Angreifer, der einen Dienst übernimmt, trotzdem keine Tokens für das ganze System ausstellen.

Sie prüfen bei jeder Anfrage, denn ein einmal gesehenes Token bleibt nicht für immer vertrauenswürdig. Außerdem kann jemand es auf einem Gerät, im Netzwerk oder in einer Logdatei kopiert haben. Also wiederholen Sie die Prüfungen von Signatur, Ablauf und Zielgruppe jedes Mal. In der Praxis ist das Auslassen dieser Prüfungen bei sensiblen Schritten wie Kontoänderungen oder Zahlungen der teuerste Fehler.

Warum sind Schlüsselverwaltung und Key Rotation wichtig?

Zunächst gilt: Gelangt der Signaturschlüssel in fremde Hände, kann jeder gültige Tokens in Ihrem Namen erzeugen. Deshalb gehört der Schlüssel nie in ein Code Repository, eine Client App oder eine Einstellungsdatei im Klartext. Nutzen Sie stattdessen einen Speicher für Geheimnisse und begrenzen Sie den Zugriff.

Außerdem ist der regelmäßige Austausch von Schlüsseln, die Key Rotation, eine gute Gewohnheit. Eine Schlüsselkennung im Header (kid) sagt dem Prüfer, welcher Schlüssel signiert hat. In der Übergangszeit akzeptiert der Prüfer dann alten und neuen Schlüssel. Für die Veröffentlichung öffentlicher Schlüssel gibt es die Formate JWK und JWKS.

Eine Warnung gilt allerdings: Vertrauen Sie dem Header nicht blind, auch wenn er auf eine Schlüsselquelle zeigt. OWASP führt das Vertrauen in Schlüsselmaterial aus dem Token Header als eigene Bedrohung auf. Legen Sie vertrauenswürdige Schlüsselquellen daher vorab auf dem Server fest.

Was ist der Unterschied zwischen JWS und JWE?

Ein JWT trägt seine Claims also nicht allein. Es steckt in einer von zwei Strukturen. JWS (JSON Web Signature, RFC 7515) signiert die Claims. JWE (JSON Web Encryption, RFC 7516) verschlüsselt sie. Wenn man im Alltag „JWT“ sagt, meint man meist die signierte JWS Form.

Ein signiertes JWT liefert Unversehrtheit und Herkunftsnachweis, aber der Inhalt bleibt lesbar. Ein verschlüsseltes JWT verbirgt dagegen den Inhalt vor allen ohne den passenden Schlüssel. Folglich reicht eine Signatur nicht, wenn die Payload ein Geheimnis enthalten muss. Lassen Sie die Information dann weg oder nutzen Sie die verschlüsselte Form.

Ein verschachteltes JWT kombiniert beides, etwa erst signieren, dann verschlüsseln. In den meisten Geschäftsanwendungen ist der beste Weg aber einfacher: Halten Sie die Payload klein, damit sie nie sensible Daten tragen muss. Dieses Design ist zudem leichter zu bauen und erzeugt weniger Fehler.

Was ist JWT im Vergleich zum Session Cookie, und was passt besser?

Zunächst führt der Server beim klassischen Session Cookie für jeden angemeldeten Nutzer einen Datensatz. Der Browser erhält dann nur eine bedeutungslose Sitzungsnummer. Andererseits liegt beim JWT die Information im Token, und der Server führt oft keinen Datensatz. Beide Modelle haben echte Stärken und Schwächen.

Schließen Sie aus der Tabelle nicht, JWT sei immer moderner. Das OWASP JWT Cheat Sheet äußert sich zu zustandslosen Nutzersitzungen mit JWT ausdrücklich zurückhaltend. Denn Abmeldung und Widerruf brauchen serverseitigen Zustand. Für eine einfache Website ist ein gut geführter Session Cookie oft sicherer und weniger aufwendig. Was ist JWT dort wert? Häufig weniger als eine saubere Cookie Sitzung.

Wie arbeiten Access Token und Refresh Token zusammen?

In der Praxis nutzen Teams zwei Tokens statt eines langlebigen. Der Client schickt das Access Token an die API, und es lebt nur kurz. Das Refresh Token dient dagegen nur dazu, ein neues Access Token zu holen, und es lebt länger. Somit begrenzt diese Trennung den Schaden, wenn jemand ein Access Token stiehlt.

1. Zunächst meldet sich der Nutzer mit Zugangsdaten oder einem Passkey an.
2. Danach stellt der Identitätsserver ein Access Token und ein Refresh Token aus.
3. Dann hängt der Client das Access Token an die API Anfragen.
4. Läuft das Access Token ab, lehnt die API die Anfrage ab.
5. Anschließend schickt der Client das Refresh Token an den Identitätsserver und erhält ein neues Access Token.
6. Schließlich widerruft der Identitätsserver das Refresh Token, wenn sich der Nutzer abmeldet oder etwas verdächtig wirkt.

Entscheidend ist also, dass der Server das Refresh Token nachverfolgen kann. Somit können Sie es widerrufen, seine Nutzung zählen und die ganze Kette schließen, sobald es Anzeichen für Diebstahl gibt. Konkrete Laufzeiten nennen wir hier nicht als Zahlen. Legen Sie sie nach Ihrem Risiko fest und prüfen Sie die aktuellen Empfehlungen.

Welche Prüfungen braucht der Server vor der Annahme eines JWT?

In der Praxis ist die Verifikation mehr als ein einzelnes „Signatur in Ordnung“. RFC 8725 (aktuelle Best Practices für JWT) und die OWASP Unterlagen empfehlen mehrere Prüfungen zusammen. Fehlt eine, wirkt ein Token gültig und kann trotzdem am falschen Ort durchgehen.

1. Zunächst prüfen Sie, ob das Token dreiteilig aufgebaut ist und sich sauber dekodieren lässt.
2. Legen Sie den erwarteten Signaturalgorithmus auf dem Server fest, statt dem Token Header zu folgen.
3. Prüfen Sie danach die Signatur mit dem richtigen Schlüssel.
4. Kontrollieren Sie das Zeitfenster mit exp und nbf.
5. Bestätigen Sie, dass iss einen Aussteller nennt, dem Sie vertrauen.
6. Bestätigen Sie, dass aud Ihren Dienst enthält.
7. Prüfen Sie, ob das Token die nötige Berechtigung trägt, und treffen Sie die eigentliche Autorisierungsentscheidung auf dem Server.

Kurz gesagt belegt die Signatur: „Niemand hat dieses Token verändert.“ Die übrigen Prüfungen beantworten dagegen: „Gilt dieses Token jetzt, hier und für diese Aufgabe?“ Wenn Sie alle durchführen, wird JWT zu einem verlässlichen Träger.

Wo speichern Sie ein JWT im Browser?

Die Speicherung ist zudem das meistdiskutierte Thema der JWT Sicherheit. Es gibt keine Antwort für alle, aber die Risiken sind dennoch klar. Ein Token an einem Ort, den Skripte der Seite lesen können, lässt sich stehlen, sobald schädlicher Code auf die Seite gelangt (XSS). Cookies bringen ein anderes Problem: Der Browser sendet sie automatisch, daher brauchen Sie einen eigenen Schutz gegen gefälschte Anfragen (CSRF).

Für Tokens im Browser wählen viele Teams ein Cookie mit den Attributen HttpOnly, Secure und einem passenden SameSite, weil Skripte es nicht lesen können. Die MDN Dokumentation zu Cookies ist dafür eine gute Primärquelle. In Mobile Apps nutzen Sie stattdessen den sicheren Speicher des Betriebssystems.

Für beide Wege gelten daher zwei Grundsätze. Erstens müssen Sie XSS Lücken schließen, denn mit einer solchen Lücke bietet keine Speicherart vollen Schutz. Zweitens halten Sie das Access Token kurzlebig, um die Folgen eines Lecks zu verkleinern. Das größere Bild der Websicherheit finden Sie in unserem OWASP Top 10 Leitfaden.

Welche JWT Sicherheitsfehler passieren am häufigsten?

Die Fehler, die Teams am häufigsten sehen, sind erstaunlich einfach. Meist entstehen sie nicht in der Bibliothek, sondern in der Art, wie man sie nutzt. Deshalb zeigt die folgende Liste, wo Sie bei einer Prüfung zuerst hinschauen.

• Sensible Daten in der Payload ablegen, obwohl sie nicht verschlüsselt ist.
• Die Signatur nie prüfen oder das Token nur dekodieren und dem Inhalt vertrauen.
• Den Algorithmus vom Token wählen lassen und Schlüsseltypen vermischen.
• Tokens ausstellen, die nie ablaufen oder viel zu lange leben.
• Das Token dort speichern, wo Skripte der Seite es lesen können.
• Die Prüfungen von iss und aud auslassen.
• Abmeldung und Widerruf nie einplanen.
• Den Signaturschlüssel im Code Repository, in Logs oder auf der Clientseite ablegen.

Jeden dieser Punkte behandeln wir in den folgenden Abschnitten. Für einen breiteren Blick auf Zugriffsprobleme hilft außerdem unser Beitrag zum 401 Unauthorized Fehler.

Warum gehören keine sensiblen Daten in die JWT Payload?

Die Payload ist nur kodiert, nicht verschlüsselt. Somit kann jeder, der das Token in die Hände bekommt, die Payload ohne Schlüssel lesen. Das kann ein Angreifer sein, aber auch ein Proxy, ein Protokollsystem oder eine Browsererweiterung, über die das Token läuft.

Deshalb haben Passwörter, Kartendaten, Gesundheitsangaben, vollständige Adressen und Ausweisnummern in der Payload nichts verloren. In der Praxis genügen eine Nutzerkennung, eine Rolle und ein Ablaufzeitpunkt. Alles Weitere schlägt der Server dann in seiner eigenen Datenbank nach.

In Systemen mit personenbezogenen Daten ist das zudem eine Frage der Compliance. Außerdem rät der Grundsatz der Datenminimierung, nur die Daten mitzuführen, die Sie wirklich brauchen. Dieser Artikel ist keine Rechtsberatung. Lesen Sie unseren Leitfaden zur DSGVO konformen Website und sprechen Sie mit Ihrer Rechtsberatung.

Was passiert, wenn die Signaturprüfung fehlt oder der Algorithmus verwechselt wird?

Prüft ein System die Signatur nie, ist das Token nur einfacher Text, den jeder ändern kann. Dann sind Szenarien möglich, in denen jemand eine Rolle ändert oder die Kennung eines anderen Nutzers einträgt. Dieser Fehler rutscht oft mit einem schnellen Prototyp in den Livebetrieb, weil jemand dachte, Dekodieren reiche aus.

Die Verwechslung von Algorithmen ist allerdings subtiler. Der Token Header nennt den Algorithmus, mit dem signiert wurde. Folgt der Server diesem Hinweis blind, kann ein Angreifer ihn zu einer Methode drängen, die er nie akzeptieren wollte. Der Standard beschreibt außerdem eine ungesicherte JWT Form. Sie gilt nur für Sonderfälle mit einer Garantie außerhalb der Signatur, und für die Nutzeranmeldung dürfen Sie sie nie akzeptieren.

Kurz gesagt ist die Abwehr einfach. Legen Sie die erlaubten Algorithmen als feste Liste auf dem Server fest, ordnen Sie den Schlüsseltyp dem Algorithmus zu und nutzen Sie eine gepflegte, aktuelle Bibliothek. Die offiziellen Empfehlungen finden Sie in RFC 8725.

Wie gehen Sie mit Ablauf und Widerruf von Tokens um?

Ein signiertes JWT bleibt gültig, bis es abläuft, und der Server kann es standardmäßig nicht „zurückrufen“. Deshalb ist ein Token ohne Ablauf die gefährlichste Wahl: Einmal gestohlen, funktioniert es ewig. Folglich braucht jedes Token einen Ablaufzeitpunkt, und beim Access Token halten Sie ihn kurz.

Trotzdem müssen Sie ein Token manchmal vorzeitig ungültig machen. Zum Beispiel meldet sich ein Nutzer ab, ändert sein Passwort oder schließt sein Konto. Das OWASP Dokument nennt dafür die wichtigsten Ansätze: eine Sperrliste widerrufener Tokens führen, eine Token Statusliste nutzen und Refresh Tokens auf dem Server nachverfolgen.

Der Traum vom völlig zustandslosen System steht also im Konflikt mit dem Wunsch nach sofortigem Widerruf. Also finden die meisten echten Anwendungen eine Balance: kurzlebiges Access Token, nachverfolgtes Refresh Token und zusätzliche Prüfung bei kritischen Aktionen. Brauchen Sie sehr starken Widerruf, ist ein serverseitiges Sitzungsmodell die ehrlichere Lösung.

Wie wirken sich Tokengröße und Performance auf Ihre Anwendung aus?

Ein Token reist bei jeder Anfrage mit. Je mehr Claims und Berechtigungslisten es enthält, desto schwerer wird jede Anfrage. Das erhöht den Netzwerkverkehr und kann an Grenzen für die Headergröße in manchen Servern oder Zwischenschichten stoßen. Alle Berechtigungen ins Token zu packen, ist daher meist eine schlechte Idee.

Besser ist es, nur das Nötigste in der Payload zu halten, etwa Kennung, Rolle und Ablauf. Detaillierte Rechte fragen Sie dann auf dem Server anhand der Nutzerkennung ab. So wirkt eine Rechteänderung sofort, und das Token bleibt klein.

Der Rechenaufwand der Signaturprüfung liegt in der Regel unter dem Aufwand einer Datenbankabfrage bei jeder Anfrage. Entscheiden Sie dennoch nicht ohne Messung. Führen Sie einen Lasttest in Ihrem eigenen System durch und lassen Sie die Ergebnisse entscheiden.

Wie hängen JWT, OAuth 2.0 und OpenID Connect zusammen?

Viele verwechseln diese drei Begriffe, dabei liegen sie auf verschiedenen Ebenen. JWT ist ein Datenformat. OAuth 2.0 ist ein Autorisierungsrahmen, mit dem eine Anwendung in Ihrem Namen begrenzten Zugriff auf einen anderen Dienst erhält. OpenID Connect ist eine Identitätsschicht auf OAuth 2.0 und sagt der Anwendung, wer der Nutzer ist.

Bei „Mit Google anmelden“ läuft zum Beispiel im Hintergrund OpenID Connect, und das ID Token kommt als JWT an. JWT zu lernen ist daher ein Grundschritt, um moderne Identitätssysteme zu lesen. Das „Token“ in der KI Preisgestaltung ist dagegen etwas völlig anderes. Bei Verwechslung hilft unser Beitrag, was ein Token in der KI ist.

Was ist der Unterschied zwischen JWT und Passkey?

Ein Passkey ist ein Weg, zu beweisen, wer der Nutzer ist. Er ersetzt das Passwort durch einen privaten Schlüssel auf dem Gerät und eine Bestätigung per Biometrie oder PIN. Ein JWT trägt dagegen das Ergebnis dieses Beweises in die späteren Anfragen. Das eine beantwortet „Wie beweise ich, wer ich bin?“, das andere „Wie trage ich diesen Beweis weiter?“.

Beide Technologien sind keine Konkurrenten, sondern arbeiten oft zusammen. Der Nutzer meldet sich mit einem Passkey an, und nach erfolgreicher Anmeldung stellt der Server ein kurzlebiges Token oder eine Sitzung aus. Passkeys im Detail erklärt unser Beitrag Was ist ein Passkey.

Beispielszenario: In einer Mobile App meldet sich der Nutzer mit einem Passkey an. Die App erhält im Hintergrund ein kurzlebiges Access Token. Die Anmeldung kommt ohne Passwort aus, aber das Token trägt die Identität weiter zwischen den Anfragen.

Wann ist JWT die richtige Wahl, und wann nicht?

Die starken Fälle sind klar: mehrere Dienste, die dieselbe Identität unabhängig prüfen, Kommunikation zwischen Mobile App und API, kurzlebige Berechtigungsweitergabe und Single Sign on. In solchen Systemen ist es ein großer Vorteil, nicht jeden Dienst an einen gemeinsamen Sitzungsspeicher anbinden zu müssen.

• Gute Wahl: Identität zwischen Diensten, kurzlebiger API Zugriff, Föderation und SSO.
• Mit Vorsicht: Lange Nutzersitzungen, Rechte, die bei der Abmeldung sofort enden müssen, und große Payloads.
• Möglicherweise unnötig: Eine klassische Website auf einem einzelnen Server oder ein einfaches Admin Panel.

Schützen Ihre Tokens eine REST oder GraphQL API, prüfen Sie auch Ihr API Design. Unser Beitrag zu GraphQL im Vergleich zu REST liefert dazu die passende Perspektive. Echtzeitverbindungen brauchen ein eigenes Konzept für die Authentifizierung, und unser WebSocket Leitfaden weist den Weg.

Was gehört in eine JWT Sicherheitscheckliste?

Die folgende Liste sammelt die Punkte, die Sie vor dem Livegang prüfen sollten. Alles bleibt auf konzeptioneller Ebene, deshalb bestätigen Sie genaue Werte in der aktuellen Dokumentation Ihres Anbieters und in den Standards.

• Prüfe ich die Signatur bei jeder Anfrage?
• Habe ich die erlaubten Algorithmen auf dem Server festgelegt?
• Liegen die Signaturschlüssel in einem sicheren Speicher für Geheimnisse?
• Hat jedes Token einen Ablauf, und ist das Access Token kurzlebig?
• Kontrolliere ich iss und aud?
• Enthält die Payload nur das Nötigste und keine sensiblen Daten?
• Kann ich Refresh Tokens nachverfolgen und bei Bedarf widerrufen?
• Habe ich Abmeldung, Passwortänderung und Kontoschließung eingeplant?
• Speichere ich das Token dort, wo Skripte der Seite es nicht lesen können?
• Läuft der gesamte Verkehr über HTTPS?

Beim letzten Punkt prüfen Sie Ihr Zertifikat mit unserem SSL Check und lesen die Grundlagen in unserem Beitrag zum SSL Zertifikat. Denn eine Signatur schützt ein Token nicht, das über eine unverschlüsselte Verbindung läuft.

Wie gehen Sie bei JWT in einem individuellen Softwareprojekt vor?

Beispielszenario: Ein Unternehmen plant ein System mit Weboberfläche, Mobile App und internem Adminbereich. Alle drei nutzen dieselben Backend Dienste. Unser Team beginnt solche Projekte mit einer Frage: An wie vielen Stellen prüfen wir Identität und Berechtigung, und wie schnell muss der Widerruf sein?

Die Antwort ändert die Entscheidung. Für eine einzelne Webanwendung kann eine solide Cookie Sitzung genügen. Bei mehreren Clients und Diensten passen ein kurzlebiges Access Token und ein nachverfolgtes Refresh Token besser. Wo diese Logik auf der Serverseite sitzt, erfahren Sie in unserem Beitrag Was ist ein Backend.

Die Authentifizierung gehört zu den kritischsten Teilen eines Produkts, also behandeln Sie sie nicht als Flicken, den man später ergänzt. Unser Team empfiehlt, diese Entscheidung in der Architekturphase zu klären. Möchten Sie ein solches Projekt mit uns planen, sehen Sie sich unsere individuelle Softwareentwicklung an.

Schlusswort: Was ist JWT am Ende? Ein hervorragendes Werkzeug, doch ein Werkzeug ist nur so sicher wie seine Nutzung. Den Standard (RFC 7519), das Best Practices Dokument (RFC 8725) und das OWASP JWT Cheat Sheet regelmäßig zu lesen, ist der verlässlichste Weg, Ihr Wissen aktuell zu halten.