Online JWT-Encoder: Tokens erstellen und signieren ohne Installation

Jeder Entwickler lernt ungefähr im selben Moment, was ein JWT ist: das erste Mal, wenn er Authentifizierung implementieren muss und jemand es vorschlägt. Sie lesen den RFC, schauen sich die base64-dekodierte Payload an, denken "huh, das ist nur JSON" — und verbringen die nächste Stunde damit, verwirrt zu sein, was der Signaturteil eigentlich tut und warum.

Die Verwirrung ist verständlich. JWTs sind in der Struktur einfach, aber subtil in den Sicherheitsimplikationen. Dieser Leitfaden konzentriert sich auf die praktische Seite: was Sie tatsächlich wissen müssen, um JWTs zum Testen und Debuggen zu erstellen und zu verwenden, und wie der JWT-Encoder bei ToolBox Hubs Ihnen das ermöglicht, ohne eine Bibliothek zu installieren oder einen Server hochzufahren.

Was ein JWT tatsächlich ist

Ein JSON Web Token besteht aus drei base64url-kodierten Strings, verbunden durch Punkte: header.payload.signature.

Der Header identifiziert den Token-Typ und den Signaturalgorithmus:

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

Die Payload enthält Claims — im Grunde Schlüssel-Wert-Paare von Informationen:

{
  "sub": "user_12345",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1714000000,
  "exp": 1714086400
}

Die Signatur ist ein kryptografischer Hash des kodierten Headers und der Payload, erstellt mit Ihrem geheimen Schlüssel. Sie macht den Token manipulationssicher — ändern Sie ein einzelnes Zeichen in der Payload, und die Signatur passt nicht mehr.

Hier ist die Sache, über die viele Leute stolpern: die Payload ist nicht verschlüsselt. Sie ist base64url-kodiert, was bedeutet, dass jeder, der den Token besitzt, ihn sofort dekodieren und lesen kann. Die Signatur beweist, dass der Token nicht manipuliert wurde, aber sie tut nichts, um den Inhalt zu verbergen. Das ist sehr wichtig dafür, was Sie hineinpacken.

Die Claims, die Sie tatsächlich verwenden

Die JWT-Spezifikation definiert eine Handvoll "registrierter Claims" — Feldnamen mit Standardbedeutungen, die Bibliotheken automatisch validieren können.

sub (Subject) — Worum es bei dem Token geht. Normalerweise eine Benutzer-ID oder Konto-Kennung. Sollte stabil und eindeutig sein. Ein häufiger Fehler: hier eine E-Mail-Adresse statt einer undurchsichtigen ID einzugeben. E-Mail-Adressen ändern sich; undurchsichtige IDs nicht.

iat (issued at) — Unix-Zeitstempel, wann der Token erstellt wurde. Nützlich zum Debuggen, und manche Validierungslogik prüft das, um Tokens abzulehnen, die aus der fernen Zukunft zu stammen scheinen (Clock-Skew-Angriffe).

exp (expiration) — Unix-Zeitstempel, nach dem der Token abgelehnt werden sollte. Das ist wichtig. Ein JWT ohne Ablauf ist für immer gültig, was bedeutet, wenn er leakt, haben Sie keine Möglichkeit außer das Secret komplett zu rotieren. Für kurzlebige Sessions sind 15-60 Minuten üblich. Für Refresh-Tokens Stunden bis Tage. Setzen Sie das immer.

iss (issuer) — Ein String, der identifiziert, wer den Token ausgestellt hat. Nützlich in Multi-Service-Umgebungen, um sicherzustellen, dass Sie Tokens aus der richtigen Quelle validieren. Ihre Validierungs-Middleware kann prüfen, dass iss mit einem erwarteten Wert übereinstimmt, und alles andere ablehnen.

aud (audience) — Für wen der Token bestimmt ist. Verhindert, dass ein für Service A ausgestellter Token gegen Service B verwendet wird. Oft eine API-Kennung oder eine Liste von Services, die den Token akzeptieren sollen.

Custom Claims sind in Ordnung und üblich. Wenn Ihre App eine role, einen plan, eine org_id oder einen anderen Kontext in den Token einbetten muss, um Datenbankabfragen bei jedem Request zu vermeiden, fügen Sie diese auch hinzu. Denken Sie nur daran: jeder kann sie lesen.

Wann Sie tatsächlich einen Online-JWT-Encoder verwenden würden

Die ehrliche Antwort lautet: nicht für die Produktion. Für die Produktion erledigt Ihr Auth-Server das Signieren — Ihr Secret verlässt nie die Serverumgebung, und Tokens werden programmatisch als Teil eines Login-Flows generiert.

Wo ein Online-Encoder wirklich nützlich ist:

Auth-Middleware ohne laufenden Auth-Server testen. Sie bauen den Backend-Endpunkt, der JWTs validiert, und wollen ihn manuell testen. Sie brauchen einen gültigen Token, der mit einem bekannten Secret signiert ist, um ihn in Postman oder curl einzufügen. Ein Online-Encoder gibt Ihnen das in Sekunden.

Auth in der lokalen Entwicklung mocken. Ihr Frontend baut gegen eine API, die Authentifizierung erfordert, aber der Auth-Service ist lokal noch nicht eingerichtet. Generieren Sie einen Token mit den richtigen Claims und einem Test-Secret, kodieren Sie ihn fest in Ihre Entwicklungsumgebung, weiter geht's. Sie veröffentlichen das nicht; Sie entblockieren die lokale Entwicklung.

Token-Validierungsfehler debuggen. Ein Token wird von Ihrem Server abgelehnt und Sie sind sich nicht sicher warum. Ist exp in der Vergangenheit? Ist iss falsch? Ist die Payload fehlerhaft? Ein Encoder lässt Sie einen bekannt guten Token erstellen, mit dem Sie vergleichen können, und ein JWT-Decoder lässt Sie den schlechten inspizieren. Zusammen sind sie ein Debugging-Loop.

JWT-Verhalten zum ersten Mal verstehen. Der beste Weg zu verstehen, was eine Bibliothek mit einem JWT macht, ist, selbst einen zu erstellen und zu beobachten, was passiert. Ablauf anpassen, Algorithmus ändern, beobachten was bricht. Ein Online-Tool macht das praktisch ohne den Aufwand von Code.

Wie HS256-Signierung funktioniert (ohne die Mathematik)

HS256 steht für HMAC-SHA256. HMAC ist eine Konstruktion, die eine Hash-Funktion (in diesem Fall SHA-256) zusammen mit einem geheimen Schlüssel verwendet, um einen Message Authentication Code zu erzeugen.

Der Prozess in einfachen Worten: nehmen Sie den kodierten Header, fügen Sie einen Punkt hinzu, fügen Sie die kodierte Payload hinzu. Geben Sie diesen String und Ihren geheimen Schlüssel in die HMAC-SHA256-Funktion. Sie bekommen einen Hash fester Länge zurück. Base64url-kodieren Sie diesen Hash und hängen Sie ihn als dritten Teil des Tokens an.

Warum funktioniert das? Weil HMAC so designed ist, dass Sie ohne Kenntnis des geheimen Schlüssels keinen gültigen Hash für eine gegebene Nachricht erzeugen können. Wenn jemand die Payload modifiziert, kann er die Signatur nicht neu berechnen, um zu passen — er bräuchte das Secret dafür. Wenn Ihr Server einen JWT validiert, führt er dieselbe HMAC-SHA256-Berechnung erneut auf den empfangenen Header und die Payload aus, vergleicht das Ergebnis mit der Signatur im Token und akzeptiert oder lehnt entsprechend ab.

Der ToolBox Hubs-Encoder macht diese Berechnung mit der eingebauten Web Crypto API des Browsers — denselben kryptografischen Primitiven, die Browser für TLS verwenden. Das wird nicht in selbstgeschriebenem JavaScript oder einer zwielichtigen Drittanbieter-Bibliothek gemacht. Das ist es wert zu wissen.

Was HS256 nicht kann

HS256 verwendet einen symmetrischen Schlüssel — dasselbe Secret, das den Token signiert, verifiziert ihn auch. Das bedeutet, jeder, der Ihre Tokens verifizieren kann, kann sie auch erstellen. In einem System, in dem ein Server Tokens ausstellt und ein anderer sie verifiziert, müssen beide Server das Secret kennen. Secrets zwischen Services zu teilen ist ein Koordinations- und Sicherheitsoberflächen-Problem.

RS256 (und ES256) verwenden asymmetrische Schlüssel. Ein privater Schlüssel signiert Tokens — nur der Auth-Server braucht das, und es verlässt diesen Server nie. Ein öffentlicher Schlüssel verifiziert Tokens — dieser kann frei verteilt, in einem JWKS-Endpunkt veröffentlicht und von jedem Service geladen werden, der Tokens verifizieren muss. Services können verifizieren, ohne die Fähigkeit zu haben, zu prägen.

Für alles, was komplexer ist als ein einzelner Backend-Service, ist RS256 normalerweise die bessere architektonische Wahl. HS256 ist einfacher einzurichten und in Ordnung für kleinere Systeme oder Szenarien, in denen Sie alle Validatoren kontrollieren.

Die Sicherheitssachen, die es wert sind, wiederholt zu werden

Stecken Sie keine sensiblen Daten in JWTs. Passwort-Hashes, Kreditkartennummern, PII, die nicht dort sein muss — nichts davon. Die Payload ist für jeden sichtbar, der den Token besitzt. Das schließt den Client, jedes Logging-System, das Auth-Header erfasst, und jeden Proxy oder CDN dazwischen ein. Behandeln Sie die JWT-Payload wie einen URL-Query-String: gehen Sie davon aus, dass sie sichtbar ist.

Verwenden Sie Test-Secrets mit Online-Tools. Selbst wenn ein Tool wirklich clientseitig ist und Ihre Daten nirgendwohin sendet, ist die Gewohnheit, Produktions-Secrets in Browser-UIs einzugeben, eine schlechte. Erstellen Sie ein Test-Secret. Verwenden Sie test-secret-do-not-use-in-production als Ihren Schlüssel, wenn Sie wollen. Behandeln Sie das echte Secret wie ein Passwort: es verlässt nicht den Server, auf dem es lebt.

Setzen Sie immer einen Ablauf. Ein JWT ohne exp ist eine ewige Berechtigung. Wenn er leakt, haben Sie ein Problem, bis Sie den Signaturschlüssel rotieren — was alle bestehenden Tokens ungültig macht und alle ausloggt. Kurzlebige Tokens plus ein Refresh-Token-Flow ist aus gutem Grund das Standardmuster.

Algorithm-Confusion-Angriffe sind real. Einige JWT-Bibliotheken hatten historische Schwachstellen, bei denen Sie den alg-Header auf none ändern konnten und die Bibliothek unsignierte Tokens akzeptiert hat. Validieren Sie immer den Algorithmus, den Ihr Server erwartet, und lehnen Sie alles andere ab. Vertrauen Sie nicht dem alg-Header aus dem Token selbst.

ToolBox Hubs vs. jwt.io

jwt.io ist das kanonische JWT-Tool und die meisten Entwickler kennen es. Es ist gut. Aber es gibt zwei Gründe, warum Sie ToolBox Hubs vorziehen könnten:

Erstens: ToolBox Hubs ist ausdrücklich Privacy-First und nur clientseitig. jwt.io wurde historisch geprüft, ob in es eingegebene Secrets möglicherweise geloggt werden. Ich sage nicht, dass jwt.io bösartig ist — aber wenn das Datenschutzmodell eines Tools nicht klar dokumentiert ist, ändert sich die Risikokalkulation. Unser Tool verarbeitet alles in Ihrem Browser.

Zweitens: ToolBox Hubs integriert sich mit verwandten Tools. Nach dem Kodieren eines JWTs können Sie direkt zum JWT-Decoder springen, um ihn zu inspizieren, die Payload durch den Hash-Generator laufen lassen, wenn Sie irgendwelche Werte hashen müssen, oder Text-Verschlüsselung/Entschlüsselung verwenden, wenn Sie symmetrische Verschlüsselung für etwas brauchen, das die JWT-Payload nicht im Klartext tragen sollte.

Trotzdem: jwt.io hat Funktionen, die wir nicht haben, einschließlich Bibliotheksauswahl und RS256-Unterstützung mit Schlüsselpaar-Generierung. Verwenden Sie das richtige Tool für das, was Sie brauchen.

Ein praktischer Workflow für die lokale Entwicklung

So verwende ich tatsächlich einen JWT-Encoder während der Entwicklung:

1. Entscheiden Sie, welche Claims der Token braucht — normalerweise sub, exp, und welche app-spezifischen Claims Ihre Middleware prüft (wie role oder org_id).

2. Setzen Sie exp auf etwas weit genug in der Zukunft, dass es während einer Debugging-Session nicht abläuft. Ich nehme normalerweise die aktuelle Unix-Zeit plus 86400 (24 Stunden). Der Timestamp-Konverter hilft beim Kopfrechnen.

3. Geben Sie ein einprägsames Test-Secret ein — etwas offensichtlich Falsches wie dev-secret-not-real.

4. Generieren Sie den Token und fügen Sie ihn in Ihren API-Client ein (Postman, curl, HTTPie, was auch immer).

5. Wenn etwas mit der Validierung schiefgeht, fügen Sie den Token in den JWT-Decoder ein, um zu bestätigen, dass die Payload richtig aussieht, und prüfen Sie dann, dass das von Ihrem Server erwartete Secret und der Algorithmus mit dem übereinstimmen, was Sie zur Generierung verwendet haben.

Dieser Loop löst 90 % der JWT-bezogenen Debugging-Verwirrung. Die restlichen 10 % sind normalerweise Clock-Skew (Ihr exp ist verschoben) oder Algorithmus-Mismatch (Sie haben HS256 generiert, Ihre Bibliothek erwartet RS256).

Was das Tool nicht tun wird

Ehrlich zu den Einschränkungen:

Keine RS256- oder ES256-Unterstützung. Asymmetrische Schlüssel-Signierung ist nicht verfügbar — Sie müssten einen privaten Schlüssel bereitstellen, und das in einer Browser-UI zu handhaben fügt Komplexität hinzu. Für RS256-Tests sind das lokale jsonwebtoken npm-Paket oder die python-jose-Bibliothek angemessener.

Kein Token-Widerruf. JWTs sind designbedingt zustandslos — einmal ausgestellt, sind sie bis zum Ablauf gültig (vorausgesetzt, die Signatur validiert). Es gibt keinen eingebauten Widerruf. Wenn Sie die Fähigkeit brauchen, bestimmte Tokens vor ihrem Ablauf zu invalidieren, brauchen Sie eine Token-Blocklist auf Ihrem Server. Der Encoder kann da nicht helfen; das ist eine architektonische Angelegenheit.

Keine JWKS-Generierung. Für RS256-basierte Systeme würden Sie auch einen JWKS-Endpunkt (JSON Web Key Set) wollen. Das liegt außerhalb des Umfangs dieses Tools.

Für alles, was im Umfang liegt — HS256-signierte Tokens zum Testen und Debuggen erstellen, JWT-Struktur verstehen, Auth in der lokalen Entwicklung mocken — erledigt der JWT-Encoder die Arbeit ohne Zeremonie.

Erste Schritte

Öffnen Sie das JWT-Encoder-Tool, geben Sie eine einfache Payload wie {"sub": "test-user", "role": "admin"} ein, setzen Sie ein Test-Secret und drücken Sie Generate. Schauen Sie sich die Ausgabe an. Fügen Sie sie dann in den JWT-Decoder ein und beobachten Sie, wie sie auseinandergenommen wird.

Wenn Sie das einmal gemacht haben, hört die JWT-Struktur auf, abstrakt zu sein. Sie wissen, was die drei Teile sind, Sie wissen, wie base64url-kodiertes JSON aussieht, und Sie wissen, dass die Signatur nur ein Hash ist. Alles andere — Bibliotheksintegration, Algorithmus-Auswahl, Claims-Validierung — baut auf diesem Fundament auf.

Verwandte Tools, die es wert sind, zusammen mit diesem geöffnet zu haben: JWT-Decoder zum Inspizieren von Tokens, Hash-Generator, um zu verstehen, was HMAC produziert, und Text-Verschlüsselung/Entschlüsselung für die Fälle, in denen base64-kodierter Klartext wirklich nicht gut genug ist.