JWT 'Invalid Signature' und andere häufige Token-Fehler erklärt

Was einen JWT-Signaturfehler tatsächlich verursacht, warum er sich von einem abgelaufenen Token unterscheidet, und wie du Header und Payload eines Tokens liest, um das echte Problem in Sekunden zu finden.

Ein JWT besteht aus drei Base64URL-kodierten Teilen, durch Punkte verbunden — header.payload.signature. Header und Payload sind einfach kodiertes JSON und können von jedem ohne jegliches Geheimnis gelesen werden; die Signatur ist der einzige Teil, der tatsächlich beweist, dass das Token von dem ausgestellt wurde, der den geheimen Schlüssel besitzt — und daher stammt fast jeder verwirrende JWT-Fehler.

'Invalid signature' bedeutet fast nie, dass das Token fehlerhaft aufgebaut ist

Dieser Fehler bedeutet, dass der Server die Signatur mit seinem eigenen geheimen Schlüssel neu berechnet hat und ein anderes Ergebnis erhielt als das im Token. Struktur und JSON des Tokens sind meist völlig gültig — die Abweichung wird fast immer durch eines von drei Dingen verursacht: der zur Verifizierung verwendete Schlüssel stimmt nicht mit dem zur Signierung verwendeten überein (häufig direkt nach einer Schlüsselrotation oder zwischen Umgebungen), der Algorithmus im Header (alg) stimmt nicht mit dem überein, was der Server erwartet, oder der Payload wurde nach dem Signieren verändert oder neu kodiert — selbst durch etwas so Kleines wie eine JSON-Neuserialisierung mit anderer Schlüsselreihenfolge oder Leerzeichen.

'Token expired' ist ein völlig anderes, viel einfacheres Problem

Dies hat nichts mit der Signatur zu tun — es bedeutet, dass die Signatur korrekt verifiziert wurde, aber der 'exp'-Claim im Payload ein Zeitstempel in der Vergangenheit ist. Das Token funktioniert genau wie vorgesehen. Die Lösung ist einfach ein neues Token zu holen (üblicherweise über einen Refresh-Token-Flow), nicht die Signierlogik anzufassen.

'alg: none' und warum es immer abgelehnt werden sollte

Die JWT-Spezifikation erlaubt technisch einen 'alg'-Wert von 'none', was bedeutet, dass das Token gar keine Signatur hat. Ein Server, der dem im Token selbst genannten Algorithmus vertraut — statt nur die Algorithmen zu akzeptieren, die er explizit erwartet — kann dazu gebracht werden, ein völlig unsigniertes, von einem Angreifer erstelltes Token zu akzeptieren. Validiere serverseitig immer gegen eine explizite Positivliste erlaubter Algorithmen, vertraue niemals dem 'alg'-Feld aus dem Token.

Wie man es wirklich in unter einer Minute debuggt

Füge das Token in einen Decoder ein und prüfe drei Dinge der Reihe nach: stimmt das 'alg' des Headers mit dem überein, womit dein Server signiert, liegt der 'exp'-Claim in der Zukunft, und enthält der Payload die Claims (wie 'sub' oder eine benutzerdefinierte Rolle), die dein Code auszulesen erwartet. In neun von zehn Fällen liegt der Fehler in einem dieser drei Felder, nicht in der Kryptografie selbst.

Unser JWT-Decoder trennt Header, Payload und Signatur sofort und markiert ein abgelaufenes Token automatisch — da alles in deinem Browser läuft, ist es sicher, ein echtes, aktives Token beim Debuggen eines Produktionsproblems einzufügen.