JWT-Signer & Verifier

Signieren Sie ein Token mit Ihrem eigenen Schlüssel, verifizieren Sie eines gegen ein Geheimnis, PEM, JWK oder eine live JWKS — und bauen Sie den Key-Set, den Ihre API veröffentlicht. Die gesamte Krypto läuft in Ihrem Browser.

Ein JWT ist nur so vertrauenswürdig wie seine Signatur. Jeder kann ein Token lesen — Dekodieren beweist nichts — darum macht dieses Tool den Teil, den ein Dekodierer nicht kann: Es signiert Tokens mit Ihrem Schlüssel (HS256/384/512, RS256/384/512, ES256/384/512, EdDSA), verifiziert sie gegen ein Geheimnis, einen PEM- oder JWK-Public-Key, eine eingefügte JWKS oder eine live JWKS-URL mit kid-Abgleich, und baut die JWKS, die Ihre eigene API veröffentlicht. Der begleitende Leitfaden signing and verifying JWTs erklärt, warum Dekodieren nicht Verifizieren ist, wie der Algorithm-Confusion-Angriff funktioniert und was „verifiziert“ beweist — und was nicht. Um ein Token ohne Schlüssel zu lesen, nutzen Sie den JWT Decoder; für die Schlüssel selbst deckt die SSH Key Suite Erzeugung und Konvertierung ab.

Zuletzt aktualisiert:

Ein Token signieren

🔒 Signieren und Verifizieren geschehen lokal mit WebCrypto. Geheimnisse und private Schlüssel werden nie gesendet, gespeichert oder protokolliert — laden Sie die Seite neu, und sie sind weg.

Ihre Schlüssel verlassen diese Seite nie

Signieren und Verifizieren nutzen die WebCrypto Ihres Browsers, mit Schlüsseln, die Sie hier einfügen oder erzeugen. Geheimnisse und private Schlüssel leben nur im Seitenspeicher: Sie werden nicht hochgeladen, nicht in localStorage oder Cookies geschrieben und stehen nie in der URL. Laden Sie die Seite neu oder schließen Sie sie, sind sie weg. Die einzige Ausnahme ist ein JWKS-URL-Abruf, den Sie selbst starten: Er sendet nur die URL, die Sie eingegeben haben, um öffentliche Schlüssel zu holen — niemals ein Geheimnis. Lesen Sie signing and verifying JWTs, bevor Sie einen Produktionsschlüssel irgendwo einfügen.

Die ehrlichen Grenzen

EdDSA braucht einen aktuellen Browser: WebCrypto-Ed25519 gibt es in älteren Browsern nicht, und diese Seite sagt das offen, statt eine Signatur vorzutäuschen. ECDSA P-256 wird als Fallback angeboten, der überall funktioniert.

Verschlüsseltes PEM (ein privater Schlüssel, der mit einer Passphrase gesperrt ist) wird in Version 1 nicht unterstützt. Die Seite lehnt es offen ab — entschlüsseln Sie es zuerst mit openssl pkcs8 -topk8 -nocrypt und fügen Sie niemals eine Passphrase in eine Webseite ein.

Ein JWKS-URL-Abruf hängt davon ab, dass der Server CORS-Header sendet. Viele Identity-Provider tun das; wenn einer es nicht tut, schlägt der Abruf ehrlich fehl und die Seite sagt Ihnen, dass Sie die JWKS stattdessen einfügen sollen. Es werden nur öffentliche Schlüssel abgerufen — eine JWKS-URL trägt niemals ein Geheimnis.

Wann Signieren das Dekodieren schlägt

Ein JWT zu dekodieren heißt, es zu lesen: Header und Payload sind base64url, und jeder, der das Token besitzt, kann beides sehen. Darum kann ein Dekodierer allein niemals die einzige Frage beantworten, die zählt — hat der Aussteller das wirklich signiert? Signieren ist die andere Hälfte der Arbeit: Wer den privaten Schlüssel (oder das HMAC-Geheimnis) besitzt, erzeugt die Signatur, und die Verifizierung spielt dieselbe Mathematik mit dem öffentlichen Schlüssel noch einmal durch. Diese Seite behält beide Hälften in Ihrem Browser, weil die beteiligten Schlüssel die sensibelsten Eingaben sind, die ein Web-Tool je verarbeitet.

Die Trennung zählt am meisten bei asymmetrischen Algorithmen. Bei HS256 ist das Geheimnis, das verifiziert, dasselbe Geheimnis, das signiert — jeder, der Ihre Tokens prüfen kann, kann sie auch erzeugen, was innerhalb eines Dienstes in Ordnung und überall sonst ein Leck ist. Bei RS256, ES256 oder EdDSA bleibt der Signierschlüssel beim Aussteller und nur der öffentliche Schlüssel reist: Ihre API kann ihre JWKS veröffentlichen, Schlüssel durch Hinzufügen einer neuen kid rotieren und jeden Verifizierer der Welt Tokens prüfen lassen, ohne ihm je die Macht zu geben, eines zu fälschen.

Was das Tool sich weigert zu tun

Zwei Weigerungen sind bewusst. Die erste ist alg: none: Ein Token, das behauptet, keine Signatur zu brauchen, wird rundweg abgelehnt, mit angezeigtem Grund — ein Verifizierer, der es akzeptiert, akzeptiert Fälschungen. Die zweite ist Algorithm-Confusion: Ein RS256-Token, das mit einem HMAC-Geheimnis angeboten wird (oder umgekehrt), scheitert mit einer ausdrücklichen Warnung, statt den Schlüssel still in der anderen Familie umzudeuten. Beides sind klassische JWT-Angriffe, und beide werden hier strukturell abgewehrt — die Schlüsselfamilie muss zur alg-Familie des Tokens passen, sonst schlägt die Verifizierung fehl.

Die dritte Weigerung ist subtiler: Diese Seite sagt Ihnen niemals, dass ein Token „vertrauenswürdig“ ist. Eine gültige Signatur beweist, dass das Token mit einem Schlüssel signiert wurde, und die Ablaufprüfung beweist, dass es innerhalb seines Fensters liegt — nicht mehr. Ob man diesem Schlüssel vertrauen sollte, ist eine Entscheidung darüber, woher er stammt: eine JWKS, die von der Well-known-URL Ihres Identity-Providers abgerufen wurde, ein öffentlicher Schlüssel, den Sie selbst gepinnt haben, ein Geheimnis, das Sie erzeugt haben. Der Leitfaden signing and verifying JWTs geht durch, was „verifiziert“ beweist und was nicht.

JWT-Begriffe, festgehalten

JWT. JSON Web Token (RFC 7519): eine kompakte, URL-sichere Art, Claims zwischen Parteien zu tragen — Header.Payload.Signature, jeweils base64url-kodiert. Der Payload ist für jeden lesbar; nur die Signatur hängt von einem Geheimnis ab.

JWS. JSON Web Signature (RFC 7515): das Signierformat unter JWTs. Ein JWT ist eine JWS, deren Payload ein JSON-Claim-Set ist.

JWK. JSON Web Key (RFC 7517): ein JSON-Objekt, das einen kryptografischen Schlüssel darstellt — kty und das Schlüsselmaterial (n/e für RSA, x/y für EC, x für Ed25519, k für ein gemeinsames Geheimnis).

JWKS. JSON Web Key Set: ein Objekt mit einem „keys“-Array — die Standardart, wie ein Aussteller seine öffentlichen Schlüssel veröffentlicht, üblicherweise unter /.well-known/jwks.json.

kid. Key ID: der Header-Claim, der sagt, welcher Schlüssel ein Token signiert hat. Ein Verifizierer gleicht ihn mit der JWKS ab; ohne ihn wird ein Set mit einem Schlüssel verwendet, und die Seite sagt das.

alg. Der Header-Claim, der den Signieralgorithmus nennt (HS256, RS256, ES256, EdDSA…). Ein Verifizierer muss die Algorithmen, die er akzeptiert, pinnen — dem token-eigenen alg-Claim zu vertrauen, ist der Confusion-Angriff.

HMAC. Hash-based Message Authentication Code: eine symmetrische Signatur — dasselbe Geheimnis signiert und verifiziert. Schnell und einfach; jeder, der das Geheimnis besitzt, kann Tokens erzeugen.

RSASSA-PKCS1-v1_5. Das RSA-Signaturschema hinter RS256/384/512: Der Hash wird verpackt und mit dem privaten Exponenten potenziert. Deterministisch — dieselbe Eingabe ergibt immer dieselben Signatur-Bytes.

EdDSA. Edwards-curve Digital Signature Algorithm: hier Ed25519 — kleine Schlüssel, schnelle Verifizierung, deterministische Signaturen. Braucht einen aktuellen Browser für WebCrypto-Unterstützung.

Häufig gestellte Fragen

Ist es sicher, einen privaten Schlüssel auf dieser Seite einzufügen?

Auf dieser Seite verlässt der Schlüssel Ihren Browser nie: Das Signieren läuft im Seitenspeicher mit WebCrypto, nichts wird hochgeladen, gespeichert oder protokolliert, und ein Neuladen löscht ihn. Das unsichere Muster ist ein serverseitiger Signierer, bei dem Ihr privater Schlüssel das Netzwerk überquert. Auch lokal gilt: Nutzen Sie ein Gerät, dem Sie vertrauen — und behandeln Sie einen eingefügten Produktionsschlüssel als kompromittiert, wenn die Maschine geteilt wird. Erzeugen Sie hier stattdessen Testschlüssel, statt echte einzufügen.

Warum lässt sich mein RS256-Token nicht mit meinem Geheimnis verifizieren?

Weil ein Geheimnis und ein RSA-Schlüssel verschiedene Familien sind, und die Seite sich weigert, sie zu mischen — diese Weigerung ist die Algorithm-Confusion-Abwehr. Ein RS256-Token braucht den öffentlichen RSA-Schlüssel des Ausstellers (PEM, JWK oder JWKS); ein Geheimnis kann nur HS256/384/512 verifizieren. Wenn Sie den öffentlichen Schlüssel in der falschen Form besitzen, konvertieren Sie ihn: Der JWKS-Tab konvertiert PEM ⇄ JWK.

Was sendet ein JWKS-URL-Abruf tatsächlich?

Eine GET-Anfrage an die URL, die Sie eingegeben haben, die JSON anfragt. Kein Schlüssel, kein Geheimnis, kein Token und keine Kennung geht mit — die Antwort ist ein Set öffentlicher Schlüssel. Wenn der Server keine CORS-Header sendet, blockiert der Browser das Lesen und die Seite sagt Ihnen, dass Sie die JWKS stattdessen einfügen sollen.

Mein Token verifiziert sich hier, aber die API lehnt es ab. Warum?

Die Verifizierung hier prüft die Signatur und das Zeitfenster gegen den Schlüssel, den Sie angegeben haben. Eine API prüft zusätzlich die Claims: den Aussteller (iss), den sie erwartet, die Audience (aud), die sie bedient, und ob die Key-ID (kid) eine ist, der sie aktuell vertraut. Ein Token, das mit einem herausrotierten Schlüssel signiert wurde, oder das für eine andere Audience erzeugt wurde, verifiziert sich mathematisch und wird trotzdem abgelehnt — zu Recht.

EdDSA funktioniert in meinem Browser nicht. Was nun?

Ed25519 braucht einen aktuellen Browser — ältere haben WebCrypto-Ed25519 gar nicht, und diese Seite sagt das, statt es vorzutäuschen. Nutzen Sie ES256 (ECDSA P-256) als Fallback: Es wird überall unterstützt, wo WebCrypto existiert, und die Seite kann den Schlüssel für Sie erzeugen. Wenn Sie Ed25519 unbedingt nutzen müssen, aktualisieren Sie den Browser.