JWT-Dekodierer & -Prüfer
Fügen Sie ein JSON Web Token ein und lesen Sie es so, wie Ihr Server es sollte: Header und Nutzlast zu lesbarem JSON dekodiert, die Zeitansprüche als Zeitlinie gezeichnet — ausgestellt, gültig ab, läuft ab, abgelaufen — und für HS256, HS384 und HS512 eine echte Signaturprüfung gegen ein Geheimnis, das Sie liefern. Alles geschieht in Ihrem Browser. Ein Token ist ein Zugangsdaten, und Zugangsdaten werden auf dieser Seite nicht in protokollierte KI-Chats oder auf Server von Fremden eingefügt.
Was ein Token ist und was Dekodieren beweist
Ein JWT sind drei durch Punkte verbundene Base64URL-Segmente: ein Header, der den Signaturalgorithmus benennt, eine Nutzlast aus Ansprüchen und eine Signatur über die ersten beiden. Das mittlere Segment — das, das jeder lesen will — ist eine Kodierung, keine Verschlüsselung: Der Base64-Dekodierer öffnet es ganz ohne Schlüssel, und darum darf ein Token nie etwas tragen, das Sie nicht auf ein Plakat drucken würden. Was die Signatur hinzufügt, ist Herkunft: Bearbeiten Sie einen Anspruch, und das HMAC passt nicht mehr — vorausgesetzt, der Prüfer prüft wirklich; die Fehler, die Vorfallberichte füllen, sind Server, die dekodierten und ohne Prüfung vertrauten, Bibliotheken, die das Token seinen eigenen Algorithmus wählen ließen, und „none“-Tokens, die als Evangelium akzeptiert wurden. Diese Seite spiegelt den ehrlichen Ablauf: alles dekodieren und lesen, die Anspruchs-Zeitlinie gegen die Uhr lesen (ein exp in der Vergangenheit ist ein totes Token, egal wie gültig die Signatur ist), die Algorithmuswarnungen beachten und erst dann prüfen — lokal, mit dem Geheimnis im selben Browser-Tab wie das Token. Wenn das Geheimnis, mit dem Sie debuggen, aus einer Konfigurationsdatei stammte, prüft der .env-Prüfer diese Datei ebenfalls ohne Übertragung; der Leitartikel Lassen Sie nie einen Chatbot Ihre Geheimnisse machen erklärt, warum die ganze Werkzeugfamilie in den Browser gezogen ist.
Häufige Fragen
Ist es sicher, hier ein Produktionstoken einzufügen?
Es ist der sicherste Ort im Netz dafür, und der Grund, warum dieses Werkzeug existiert. Das Dekodieren geschieht in Ihrem Browser, im Code dieser Seite: Das Token wird nie übertragen, gespeichert oder protokolliert. Vergleichen Sie die Alternativen, die Menschen tatsächlich nutzen — KI-Chats, die das Gespräch auf den Servern eines Dritten behalten, und „Online-JWT-Dekodierer“, deren Server sieht, was immer Sie einfügen. Ein Token ist ein lebender Zugang, bis es abläuft; überall, wo es eingefügt wird, kann es von dort wieder abgespielt werden. Hier geht es nirgendwohin — dieselbe Nur-lokal-Regel wie beim .env-Prüfer.
Wenn jeder ein JWT dekodieren kann, warum ist das kein Sicherheitsloch?
Weil Dekodieren nie der Schutz war. Ein JWT ist eine signierte Aussage, keine verschlüsselte: Die Nutzlast ist Base64URL — eine Kodierung, lesbar für jeden, der das Token hält — und die Sicherheit lebt in der Signatur, die beweist, dass die Aussage vom Schlüsselinhaber ausgestellt wurde und nicht verändert ist. Die klassische Katastrophe ist ein Entwickler, der die Nutzlast als geheim behandelt, oder ein Server, der die Signatur nicht prüft, sodass eine von Hand bearbeitete Nutzlast glatt durchsegelt. Der Artikel Base64 ist keine Verschlüsselung behandelt die Kodierungsverwechslung unter beidem.
Warum können Sie hier HS256 prüfen, aber nicht mein RS256-Token?
HS256 ist symmetrisch: Ein gemeinsames Geheimnis signiert und prüft, also kann ein Geheimnis, das Sie tippen, lokal mit HMAC geprüft werden. RS256 ist asymmetrisch: Es wird mit einem privaten Schlüssel signiert und mit dem passenden öffentlichen Schlüssel geprüft, den diese Seite Sie fragen müsste — und eine Seite, die zum Einfügen von Schlüsseln einlädt, lehrt eine Gewohnheit, die in einem geleakten privaten Schlüssel endet. Prüfen Sie RS256-Tokens mit dem veröffentlichten JWKS des Ausstellers in Ihrem eigenen Code oder Werkzeug, und fügen Sie niemals einen privaten Schlüssel in irgendeine Website oder einen Chat ein, auch nicht in diesen.
Was bedeutet „alg: none“ und warum die rote Warnung?
Es bedeutet, dass das Token erklärt, unsigniert zu sein — und ein Server, der diese Erklärung ehrt, akzeptiert jede Nutzlast von jedem, ohne Schlüssel. Es war eine echte, wiederholte Schwachstellenklasse: Bibliotheken, die dem eigenen alg-Feld des Tokens trauten, konnte ein „none“-Token mit einer Admin-Nutzlast untergeschoben werden. Die Warnung ist laut, weil die richtige Reaktion laut ist: Ein none-Token ist unauthentifizierte Daten, und jedes System, das eines akzeptiert, hat konstruktionsbedingt eine Authentifizierungsumgehung.
Die Signatur stimmt — bin ich fertig?
Sie haben bewiesen, dass das Token von einem Inhaber des Geheimnisses geprägt wurde und sein Inhalt unverändert ist. Sie haben nicht bewiesen, dass es für Sie bestimmt ist (prüfen Sie den aud-Anspruch), dass es aktuell ist (die Zeitlinie oben zeigt exp und nbf) oder dass das Geheimnis selbst stark ist — HS256 mit einem erratbaren Geheimnis wie „secret“ fällt offline Brute Force zum Opfer, wonach jeder Tokens prägen kann, die Ihre Prüfung segnen wird. Prüfung ist eine Zeile des Audits, nicht das ganze Audit.