Zum Hauptinhalt springen
Validatoren

HMAC-JWT-Prüfer

Prüft kompakte HS256-, HS384- oder HS512-JWT-Signaturen mit einem wörtlichen UTF-8-Secret und meldet Struktur sowie exp-, nbf- und iat-Status lokal. Unverzichtbar für Backend-Entwickler und Sicherheitsingenieure, die JWT-Token auf Authentizität prüfen, Ablaufzeiten validieren und TokenIntegrität vor der Nutzung bestätigen müssen.

JWT-Werkzeuge

Kurz erklärt

Geprüft werden HMAC-Integrität für HS256/384/512 und grundlegende NumericDate-Zeiten; RSA/ECDSA, Issuer, Audience, Nonce und Autorisierung fehlen.

Unterstützte Funktionen

  • Validiert dieselbe dreiteilige Base64URL-/JSON-Struktur wie JWT Decoder und liest alg aus dem geschützten Header.
  • Nutzt Web Crypto für HS256, HS384 und HS512; die im Secret-Feld eingegebenen Zeichen werden wörtlich als UTF-8-Schlüsselbytes verwendet.
  • Markiert exp zum/ vor aktuellen Browserzeitpunkt als abgelaufen, zukünftiges nbf als inaktiv und zukünftiges iat als Warnung.
  • Kennzeichnet RSA, ECDSA, PSS und none als nicht geprüft; iss, aud, sub, nonce, typ, Schlüssellänge und Algorithmus-Policy werden nicht validiert.

HMAC-JWT-Prüfer verwenden

Dieser implementierungsspezifische Ablauf für HMAC-JWT-Prüfer entspricht den tatsächlichen Bedienelementen und Grenzen des Browser-Arbeitsbereichs.

  1. 1

    Schritt 1

    Exakte Quelle angeben

    Das originale kompakte Token mit drei Teilen einfügen/importieren und die exakten header.payload-Bytes bewahren.

  2. 2

    Schritt 2

    Vorgang wählen

    Prüfen, dass alg HS256/384/512 ist, und das gemeinsame Secret wörtlich eingeben – nicht automatisch als Base64 oder Hex interpretieren.

  3. 3

    Schritt 3

    Verfügbare Optionen einstellen

    Live aktiviert lassen oder „Validieren“ drücken, um Web Crypto über den originalen Signing Input auszuführen.

  4. 4

    Schritt 4

    Lokalen Vorgang ausführen

    Struktur, Algorithmus, Signatururteil, exp-/nbf-Fehler und iat-Warnung getrennt bewerten.

  5. 5

    Schritt 5

    Ergebnis prüfen und weiterarbeiten

    Vor Akzeptanz Algorithmus, Issuer, Audience, Nonce, Zeittoleranz und Berechtigungen in der echten Anwendung erzwingen.

Häufige Fehler

Base64- oder Hex-Text als automatisch dekodierten Schlüssel eingeben

Folge: TextEncoder kodiert exakt die Zeichen; repräsentierte Schlüsselbytes stimmen dann nicht überein.

Lösung: Dasselbe wörtliche Secret wie der Aussteller verwenden oder einen Verifier mit explizitem Key-Import wählen.

„Struktur gültig“ als „Signatur gültig“ lesen

Folge: Struktur kann stimmen, obwohl Secret fehlt, Algorithmus unbekannt oder HMAC falsch ist.

Lösung: Ein ausdrückliches „Signatur: gültig“ verlangen und alle Fehler/Warnungen getrennt prüfen.

RS256 oder ES256 mit einem Shared Secret versuchen

Folge: Asymmetrische Algorithmen brauchen den passenden öffentlichen Schlüssel und Import; hier sind nur HMAC-SHA-2-Varianten implementiert.

Lösung: Eine gepflegte JOSE-Bibliothek mit vertrauenswürdigem JWK/JWKS und strikter Policy verwenden.

Bewährte Verfahren

  • Erwarteten Algorithmus aus vertrauenswürdiger Konfiguration wählen, nie aus beliebigem Tokenwert.
  • Produktionssecrets trotz lokaler Prüfung von Screensharing, Tickets, Erweiterungen und Clipboard-Verlauf fernhalten.
  • Clock-Skew, Issuer, Audience und Nonce im empfangenden Dienst prüfen; das Browserergebnis ist keine Autorisierung.

Verbundene Abläufe

Browser-Einschränkungen

  • Kryptografisch geprüft werden nur HS256/384/512; RSA, ECDSA, PSS, none, JWE und JWKS-Ermittlung fehlen.
  • Web Crypto hängt von Browserumgebung/secure context ab; Token und Secret bleiben während der Nutzung im Seitenspeicher.
  • Keine einstellbare Toleranz, Issuer-/Audience-/Nonce-Prüfung, crit-Header-Verarbeitung, Mindestschlüssellänge oder Widerrufsabfrage.

Verbindliche Quellen

RFC 7519: JSON Web Token (JWT)Herausgeber: IETF / RFC Editor · Geprüft: 2026-07-26RFC 7518: JSON Web Algorithms (JWA)Herausgeber: IETF / RFC Editor · Geprüft: 2026-07-26Web Cryptography Level 2Herausgeber: W3C · Geprüft: 2026-07-26

Konkrete Beispiele

Eingabe
Token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c; Secret your-256-bit-secret
Ergebnis
Web Crypto bestätigt, dass HMAC zu den exakten header.payload-Bytes und dem wörtlichen Secret passt.

Die Beispielsignatur ist HMAC-SHA-256 über die ersten beiden Segmente mit UTF-8-Schlüssel „your-256-bit-secret“; exp fehlt.

Häufig gestellte Fragen

Welche JWT-Algorithmen kann diese Seite wirklich prüfen?

Nur HS256, HS384 und HS512. Andere alg-Werte können strukturell gültig sein, liefern aber „nicht geprüft“ mit Warnung.

Reicht ein gültiges HMAC für die Annahme durch meine API?

Nein. Die API muss Schlüssel/Issuer vertrauen, Audience und Algorithmus verlangen, Laufzeit/Nonce prüfen und Subject/Scopes autorisieren.

Wie wird das Shared Secret interpretiert?

TextEncoder wandelt exakt die eingegebenen Zeichen in UTF-8 um; kein Base64-, Hex-, JWK- oder KDF-Schritt findet statt.

Warum ist ein korrekt signiertes Token trotzdem abgelaufen?

Integrität und Laufzeit sind unabhängig; exp zum oder vor der aktuellen Unix-Sekunde erzeugt trotz korrektem HMAC einen Fehler.

Ist das Secret im heruntergeladenen Prüfbericht enthalten?

Nein. Der Bericht enthält nur Struktur, Algorithmus und Signaturstatus; im Eingabefeld/RAM bleibt das Secret bis zum Löschen.

Datenschutz und Offline-Verhalten

Token und Shared Secret werden nur im Browser-RAM durch Web Crypto verwendet, nicht hochgeladen und nicht in den Downloadbericht geschrieben. Nach Abschluss beide Felder und gegebenenfalls den Clipboard-Verlauf löschen.