Als ich zum ersten Mal einen defekten Auth-Flow auf einer Laravel-API debuggen musste, verschwendete ich einen Nachmittag, weil ich kein Token meines Vertrauens produzieren konnte. Die Middleware gab immer wieder 401 zurück, und ich konnte nicht sagen, ob der Fehler in meinem Bestätigungscode oder in dem Token, den ich fütterte, war Ich brauchte einen bekannten JWT mit einem bestimmten sub‘ein bestimmtes Verfallsdatum, und ein Geheimnis, das ich kontrollierte, damit ich eine Seite des Problems isolieren konnte Das Kopieren eines zufälligen Tokens aus einer Stack Overflow-Antwort tat das Gegenteil von Hilfe, denn es war mit einem Geheimnis signiert, das ich nicht hatte.
Das ist die Lücke, die ein JWT-Generator füllt Es ist kein Produktionssignaturdienst Es ist ein Bank-Tool für den Moment, in dem Sie etwas bauen oder testen, das JSON Web Tokens verbraucht und Sie brauchen ein gültiges auf Abruf, mit den genauen Ansprüchen und dem genauen Geheimnis, das Sie wählen Dieser Leitfaden behandelt, wie das Tool funktioniert, wie ein JWT zusammengebaut und signiert wird und die praktischen Fälle, in denen die manuelle Generierung eines Tokens Ihnen Echtzeit spart.
tl; dr: Ein JWT-Generator verwandelt eine JSON-Nutzlast plus ein Geheimnis in ein signiertes Token Fügen Sie Ihre Ansprüche ein, wählen Sie HS256, HS384 oder HS512, geben Sie das Geheimnis ein und kopieren Sie das Token Die JWT-Generator Zeichen mit dem Browser Web Crypto API, so dass die Nutzlast und das Geheimnis nie verlassen Ihre Maschine Verwenden Sie es, um Test-Token mit einem bekannten
subEin gesetzter Ablauf oder ein absichtlich abgelaufener AblaufexpUm Ihre API' s-Fehlerpfade auszulesen, koppeln Sie es mit dem JWT-Decoderdrohen
Was ist ein JWT und was produziert der Generator?
Ein JSON Web Token ist eine kompakte, URL-sichere Möglichkeit, eine Reihe von Ansprüchen darzustellen. Die Struktur wird durch RFC 7519 definiert und die signierte Form, die fast jeder mit "a JWT und Quot; meint ist eine JSON-Websignatur gemäß RFC 7515. Ein signiertes Token besteht aus drei Teilen, die durch Punkte verbunden sind: header.payload.signaturedrohen
Der Header ist ein kleines JSON-Objekt, das den Signaturalgorithmus und den Token-Typ benennt, etwa { "alg": "HS256", "typ": "JWT" }. Die Nutzlast ist ein JSON-Objekt der Ansprüche: um wen es sich bei dem Token handelt, wann es abläuft und welche benutzerdefinierten Felder Ihre Anwendung hinzufügt Sowohl der Header als auch die Nutzlast sind Base64url-kodiert, was gewöhnliche Base64 mit zwei Zeichenersatz und ohne Auffüllung ist, genau wie RFC 7515 es vorgibt. Die Signatur ist ein über die ersten beiden Teile berechneter Tastenhash.
Der Generator montiert alle drei. Sie liefern die Nutzlast und das Geheimnis, er baut den Header auf, kodiert beide Segmente, berechnet die Signatur und verbindet sie. Die Ausgabe ist eine Zeichenfolge, die Sie direkt in eine ablegen können Authorization: Bearer Kopfball, ein Testgerät oder ein curl Befehl.
Eines lohnt es sich, vorweg zu sein: ein signiertes JWT ist codiert, nicht verschlüsselt. Wer das Token hält, kann die Nutzlast mit Base64url dekodieren und jeden Anspruch darin lesen. Die Signatur verbirgt den Inhalt nicht. Sie beweist nur, dass der Inhalt nicht von jemandem ohne den Schlüssel geändert wurde. Geben Sie niemals ein Passwort, einen API-Schlüssel oder irgendetwas anderes ein, das Sie dem Benutzer nicht in einer JWT-Nutzlast anzeigen würden.
Wie funktioniert die Unterzeichnung?
Für die HMAC-Familie, mit der dieses Tool signiert, ist die Signatur HMAC(secret, header + "." + payload). HMAC ist eine durch RFC 2104 definierte verschlüsselte Hash-Konstruktion, und die JWA-Spezifikation, RFC 7518, ordnet die drei Namen des JWT-Algorithmus darauf ab: HS256 verwendet HMAC mit SHA-256, HS384 verwendet SHA-384 und HS512 verwendet SHA-512.
Die wichtige Eigenschaft ist die Symmetrie Das gleiche Geheimnis erzeugt und verifiziert die Signatur, wenn Ihr Server ein Token erhält, berechnet es neu HMAC(secret, header + "." + payload) Über die empfangenen ersten beiden Segmente und prüft, ob das Ergebnis dem Signatursegment entspricht, wurde ein einzelnes Byte der Nutzlast verändert, stimmt der neu berechnete Hash nicht überein und die Überprüfung schlägt fehl Das ist die gesamte Integritätsgarantie.
Weil es symmetrisch ist, ist das Geheimnis das ganze Spiel Jeder mit dem Geheimnis kann gültige Token für Ihr System prägen, weshalb der Generator die Signierung in Ihrem Browser durch die Web Crypto API ausführt und das Geheimnis nirgendwo weitergibt, Sie können dies bestätigen, indem Sie Ihren Browser öffnen's Netzwerk-Tab, während Sie ein Token generieren: es gibt keine Anfrage Das ist wichtiger, als es klingt, denn das Einfügen eines Live-Produktions-Signierungsgeheimnisses in ein zufälliges Web-Tool, das das Telefon zu Hause die Schlüssel zu Ihrer Authentifizierung übergibt.
RS256 und ES256, die asymmetrischen Algorithmen, funktionieren unterschiedlich: Ein privater Schlüsselzeichen und ein passender öffentlicher Schlüssel verifiziert. Das ist die richtige Wahl, wenn viele Dienste Token verifizieren müssen, aber nur einer sollte sie ausgeben können. Dieses Tool bietet sie bewusst nicht an, denn wenn Sie mit ihnen unterschreiben, müssen Sie einen privaten Schlüssel in eine Webseite einfügen, und das ist eine Gewohnheit, die es wert ist, nie damit anzufangen.
So verwenden Sie den JWT Generator
Schritt 1: Schreiben Sie die Nutzlast
Geben Sie Ihre Ansprüche als JSON-Objekt ein Ein minimales Beispiel ist { "sub": "1234567890", "role": "admin" }drohen der sub Anspruch ist Gegenstand, in der Regel eine Benutzer-ID Sie können alle benutzerdefinierten Felder hinzufügen, die Ihre Anwendung liest, wie z role, scope, tenant_id, oder email. Das Tool behält alles, was Sie hier einfügen, genau so, wie es geschrieben steht.
Schritt 2: Fügen Sie die Zeitansprüche hinzu
Ausgegebener Urlaub und die Werkzeugstempel iat Mit der aktuellen Unix-Zeit Legen Sie einen Ablauf in Sekunden fest, um ein exp Anspruch berechnet als jetzt plus dieser Offset Für einen fünfzehnminütigen Zugriffstoken geben Sie 900 ein Für einen einstündigen Token geben Sie 3600 ein Dies sind die Ansprüche, auf die die meisten Authentifizierungsfehler zurückgehen, sodass sie korrekt berechnet werden, und zwar in Sekunden seit der Epoche und nicht in Millisekunden, um einen häufigen Fehler zu beseitigen.
Schritt 3: Wählen Sie den Algorithmus und das Geheimnis
Wählen Sie HS256, es sei denn, Sie haben einen Grund, HS384 oder HS512. Geben Sie das Signaturgeheimnis in das Feld ein Dann wählen Sie, wie das Geheimnis interpretiert wird: Klartext verwendet die UTF-8 Bytes von dem, was Sie eingeben, während base64url und hex die Zeichenfolge zuerst in Rohbytes dekodieren Diese Wahl ist wichtig, weil viele Systeme das Geheimnis speichern, das bereits base64-kodiert ist, und wenn Sie die kodierte Zeichenfolge als Klartext einspeisen, erzeugen Sie eine Signatur, die nicht übereinstimmt.
Schritt 4: Kopieren Sie das Token
Das signierte JWT erscheint zusammen mit einer dekodierten Vorschau des Headers und der Nutzlast, sodass Sie jeden Anspruch bestätigen können, bevor Sie es verwenden Kopieren Sie es und fügen Sie es ein, wo immer Sie es benötigen.
Warum einen Token von Hand generieren?
Testen Sie Ihre API's glücklicher Weg
Wenn Sie Middleware schreiben, die JWTs validiert, benötigen Sie ein Token, das Ihr Code akzeptieren sollte Generieren Sie eines signiert mit demselben Geheimnis, das Ihr Prüfer verwendet, mit einem gültigen exp, und bestätigen Sie die Anfrage zurückgibt 200. Wenn es nicht tut, ist der Fehler in Ihrer Verifizierungslogik, nicht das Token Dieser einzige Isolationsschritt ist der Grund, warum ich am häufigsten nach dem Tool greife.
Testen der Ausfallpfade
Eine robuste API lehnt die Rechtstoken aus den richtigen Gründen ab Generieren Sie ein Token mit einem exp Bereits in der Vergangenheit, um zu bestätigen, dass Sie den richtigen abgelaufenen Token-Fehler zurückgeben Generieren Sie einen mit einem nbf In Zukunft, um den noch nicht gültigen Pfad zu testen Generieren Sie einen mit dem falschen Geheimnis signierten, um Ihre Signaturprüfung läuft zu bestätigen Diese negativen Fälle sind diejenigen, die ungetestet versendet werden, und ein Generator macht sie zu einem zweiunddreißigsten Job.
Reproduzieren eines Fehlers von einem bestimmten Benutzer
Support meldet ein Problem, das nur bei Accounts mit einer bestimmten Rolle auftritt Generieren Sie ein Token mit genau dem role Anspruch und den betroffenen Benutzer's sub, und Sie können die Anfrage lokal reproduzieren, ohne Produktionsdaten zu berühren oder den Benutzer nach seinem echten Träger-Token zu fragen, was Sie ohnehin nie tun sollten.
Lokale Entwicklung säen
Neue Entwickler in einem Team benötigen ein funktionierendes Token, um geschützte Endpunkte zu treffen, während die Front-End-Authut noch erstellt wird Ein generiertes Token, das mit dem lokalen Entwicklungsgeheimnis signiert ist, sperrt sie sofort.
HS256 vs. HS384 vs. HS512: Was sollten Sie verwenden?
| Algorithmus | Hasch | Signaturgröße | Mindestschlüssellänge | Wann zu verwenden |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 Bytes | 32 Bytes | Die Voreinstellung Schnell, breit unterstützt, sicher für fast alle Verwendungen |
| HS384 | SHA-384 | 48 Bytes | 48 Bytes | Wenn eine Richtlinie oder ein Standard SHA-384 erfordert |
| HS512 | SHA-512 | 64 Bytes | 64 Bytes | Hochsicherheitskontexte, oder wenn Sie bereits auf SHA-512 standardisieren |
Die praktische Antwort lautet HS256, sofern nicht etwas Externes etwas anderes erfordert RFC 7518 verlangt, dass der Schlüssel mindestens so lang ist wie der Hash-Ausgang, also 32 Bytes für HS256, 48 für HS384 und 64 für HS512. Der Generator warnt, wenn Ihr dekodiertes Geheimnis kürzer als das Minimum ist, weil ein kurzer Schlüssel die Signatur unabhängig vom Namen des Algorithmus schwächt Ein längerer Algorithmus mit höherer Nummer fixiert kein schwaches Geheimnis; Auf ein zufälliges Geheimnis mit richtiger Länge kommt es an.
Häufige Fehler und wie man sie vermeidet
Die häufigste ist eine geheime Nichtübereinstimmung durch Kodierung Ihr Framework speichert das Geheimnis als base64, Sie fügen die base64-Zeichenfolge als Klartext ein, und jetzt unterscheiden sich die Schlüsselbytes von dem, was Ihr Prüfer verwendet Die Signaturen stimmen nie überein und Sie jagen einen Phantomfehler. Beheben Sie es, indem Sie die richtige geheime Kodierung im Tool auswählen, damit die Rohschlüsselbytes auf beiden Seiten identisch sind.
Die zweite ist verwirrende Sekunden und Millisekunden Die registrierten Zeitansprüche in RFC 7519 werden alle in Sekunden seit der Unix-Epoche gemessen JavaScript' s Date.now() Millisekunden zurückgibt Wenn Sie berechnen exp Selbst und vergessen Sie, durch 1000 zu dividieren, Ihr Token scheint in fünfzigtausend Jahren zu verfallen, was einige strenge Prüfer ablehnen werden. Wenn Sie den Generator die Behauptungen berechnen lassen, wird dies vollständig vermieden.
Die dritte ist die Nutzlast als privat zu behandeln Ist es nicht Wenn man versucht ist ein Geheimnis in einem Claim zu speichern, hört auf Jeder mit dem Token kann es lesen Speichern Sie nur das was Sie mit dem Tokenhalter sehen wohl haben, und halten Sie wirklich geheime Daten auf dem Server.
Wo JWTs neben andere Tools passen
Hat man einen Token generiert, ist der natürliche nächste Schritt, diesen wieder zu lesen Die JWT-Decoder Teilt jedes Token in seinen Header und seine Nutzlast auf und markiert ein abgelaufenes expSo bestätigen Sie, dass der Generator das produziert hat, was Sie beabsichtigt haben Wenn Sie auch Geheimnisse generieren, ist die Hash-Generator Berechnet SHA-Hashes auf der Clientseite und die Passwort-Generator Erzeugt die Art von langer zufälliger Zeichenfolge, die überhaupt erst ein gutes HMAC-Geheimnis macht Wenn Sie die Base64url Schritt für Hand verstehen wollen, wird die Base64-Encoder/Decoder Zeigt die gleiche reversible Transformation, die den Header und die Nutzlast in ihre codierte Form verwandelt. Und wenn Sie eine zufällige Kennung benötigen, um in eine zu fallen sub oder jti Anspruch, die UUID-Generator Ihnen eine im richtigen Format.
Für das breitere Bild, warum browserbasierte Tools sensibles Material von Servern Dritter fernhalten, ist die Datenschutz in Online-Tools Leitfaden erklärt das clientseitige Modell und das Webentwickler-Toolkit Rundet die Dienstprogramme auf, die gut mit Token-Arbeiten gekoppelt sind.
Wie überprüft ein Server das von Ihnen generierte Token?
Es hilft zu wissen, was auf der anderen Seite passiert, denn es erklärt, warum das Geheimnis und die Behauptungen genau stimmen müssen Wenn Ihre API ein Token erhält, macht eine Bibliothek wie jsonwebtoken, jose oder PyJWT drei Dinge der Reihe nach. Sie teilt das Token auf den Punkten auf und Base64url dekodiert den Header, um das zu lesen alg. Es berechnet die Signatur neu header.payload Das konfigurierte Geheimnis zu verwenden und vergleicht es, Byte für Byte, mit dem Signatursegment Und es prüft die registrierten Ansprüche: ist exp In der Vergangenheit, ist nbf In Zukunft, tut iss und aud Übereinstimmung mit dem, was die API erwartet.
Jeder dieser Checks ist etwas zugeordnet, das der Generator Ihnen die Kontrolle überlässt, wenn die Überprüfung an der Signatur fehlschlägt, unterscheidet sich das Geheimnis oder seine Kodierung zwischen den beiden Seiten. Wenn es fehlschlägt exp, ist der Token abgelaufen, den Sie möglicherweise absichtlich veranlasst haben, diesen Pfad zu testen, Wenn er am alg, Sie haben ein Token mit einem Algorithmus generiert, für den der Verifizierer nicht konfiguriert ist, was selbst eine nützliche Sache ist, die es zu entdecken gilt. Wenn Sie Token mit bewussten Variationen generieren, können Sie genau abbilden, welche Überprüfung Ihre API durchsetzt und welche sie stillschweigend überspringt.
Ein Wort auf der alg Header speziell. RFC 7515 definiert none Als gültiger Algorithmus für ein vorzeichenloses Token würden frühe Bibliotheken einem Token vertrauen, das behauptet alg: none und die Verifizierung ganz überspringen Das ist die klassische JWT-Schwachstelle Moderne Bibliotheken lehnen sie standardmäßig ab, aber der Generator bietet die none Option genau, damit Sie ein vorzeichenloses Token auf Ihre API abfeuern und bestätigen können, dass es nein sagt. Wenn Ihre API jemals eines akzeptiert, haben Sie einen schwerwiegenden Fehler gefunden.
Wie sollte man mit Geheimnissen und Token-Speicher umgehen?
Das Geheimnis, mit dem Sie unterschreiben, verdient die gleiche Sorgfalt wie ein Datenbankpasswort Ein gutes HMAC-Geheimnis ist eine lange, zufällige Zeichenfolge, keine einprägsame Phrase, denn die HMAC-Sicherheit hängt davon ab, dass der Schlüssel unermesslich ist Erzeugen eines mit einem Passwort-Tool und Speichern in Ihrer Umgebungskonfiguration, niemals in der Quellsteuerung, ist die Basislinie Denken Sie beim Drehen daran, dass jedes mit dem alten Geheimnis signierte Token ungültig wird, sobald der Prüfer wechselt, weshalb Produktionssysteme normalerweise mehr als ein gültiges Geheimnis während eines Rotationsfensters unterstützen.
Auf der Client-Seite, wo Sie den fertigen Token aufbewahren, kommt es genauso darauf an, wie Sie ihn unterschreiben Ein Token in localStorage Jegliches JavaScript auf der Seite lesbar ist, so dass ein einzelner Cross-Site-Scripting-Fehler einem Angreifer einen gültigen Anmeldeinformationen. Ein httpOnly, Secure, SameSite Cookie ist für Skripte unsichtbar, was diesen Pfad auf Kosten des CSRF-Schutzes schließt. Das übliche Muster ist ein kurzlebiges Zugriffstoken, das im Speicher gespeichert wird, und ein langlebiger Aktualisierungs-Token in einem httpOnly Cookie. Nichts davon ändert die Art und Weise, wie Sie ein Token generieren, aber es ist der Kontext, der die Verwendung eines generierten Tokens sicher macht, und nicht eine Haftung.
FAQ
Wie generiere ich ein JWT?
Fügen Sie Ihre Ansprüche als JSON-Objekt ein, wählen Sie einen Signaturalgorithmus wie HS256 aus und geben Sie das Geheimnis ein. Das Tool base64url codiert den Header und die Nutzlast, berechnet die HMAC-Signatur und gibt das fertige Token zurück, das Sie kopieren können. Alles läuft in Ihrem Browser.
Welche Signieralgorithmen werden unterstützt?
HS256, HS384 und HS512, die HMAC-Familie, plus ein unsigniertes & quot;none" Option zum Testen. RS256 und ES256 werden bewusst nicht angeboten, da sie mit einem privaten Schlüssel signieren, und das Einfügen eines privaten Schlüssels in eine Webseite ist ein Sicherheitsrisiko, das am besten vermieden werden kann.
Wird mein Geheimnis an einen Server geschickt?
Nein. Die Signatur läuft vollständig in Ihrem Browser über die Web Crypto API, sodass das Geheimnis und die Nutzlast Ihr Gerät niemals verlassen. Sie können dies im Tab DevTools Network bestätigen, und das Tool funktioniert nach dem Laden weiterhin offline.
Wie stelle ich den Token auf verfallen?
Geben Sie einen Ablauf in Sekunden ein und das Tool fügt einen hinzu exp Anspruch gleich der aktuellen Zeit plus so viele Sekunden Für einen Fünfzehn-Minuten-Token geben Sie 900. Lassen Sie das Feld leer, um wegzulassen exp Ganz.
Warum sollte das Geheimnis mindestens 32 Bytes betragen?
RFC 7518 benötigt einen HMAC-Schlüssel mindestens so lange wie der Hash-Ausgang, der bei HS256 32 Byte, bei HS384 48 und bei HS512 64. Ein kürzeres Geheimnis schwächt die Signatur, so dass das Tool warnt, wenn das dekodierte Geheimnis zu kurz ist.
Kann ich einen unsignierten Token erstellen?
Ja. alg none auswählen und das Tool erzeugt einen Header.payload. token mit einer leeren Signatur Dies dient nur zum Testen, wie Ihre API mit nicht signierten Token umgeht; die meisten Bibliotheken lehnen alg:none standardmäßig ab, und das sollten Sie auch.
Ist ein generiertes JWT verschlüsselt?
Nr. Ein signiertes JWT ist codiert, nicht verschlüsselt: Jeder kann den Header und die Nutzlast mit 64url-Decodieren und jeden Anspruch lesen. Die Signatur beweist nur, dass der Inhalt nicht geändert wurde. Legen Sie niemals Passwörter oder Geheimnisse in die Nutzlast.
