JWT-Verifier

Er prüft die Signatur anhand des von dir angegebenen Schlüssels und vergleicht dann die Claims exp und nbf mit der aktuellen Zeit. Das Ergebnis ist nur dann gültig, wenn die Signatur übereinstimmt und keine der Zeitprüfungen fehlschlägt. Claims wie iss, aud oder sub werden im Payload angezeigt, aber nicht mit erwarteten Werten verglichen.

Füge für HS256, HS384 und HS512 das gemeinsame Geheimnis als Text oder als oct JWK ein. Für RSA-, EC- und EdDSA-Tokens kannst du einen öffentlichen PEM-Schlüssel (SPKI oder PKCS #1), ein X.509-Zertifikat, einen öffentlichen oder privaten JWK, ein JWKS mit bis zu 50 Schlüsseln oder einen privaten PEM-Schlüssel einfügen. Von diesem wird nur der öffentliche Teil verwendet.

Wenn der Token-Header ein kid enthält, wird der Schlüssel mit demselben kid im Satz verwendet. Gibt es keine Übereinstimmung, nennt die Fehlermeldung das kid. Ohne kid muss der Satz genau einen Schlüssel enthalten. So wählen die meisten Server Schlüssel aus einem jwks_uri-Dokument aus.

Bei „Use the token's alg“ stammt der Algorithmus aus dem Token-Header, aber der Schlüssel muss weiterhin dazu passen. Ein öffentlicher RSA-Schlüssel kann also niemals als HMAC-Geheimnis verwendet werden. Wähle einen bestimmten Algorithmus aus, um zusätzlich vorauszusetzen, dass das Token ihn verwendet. So sollte ein Server seinen erwarteten Algorithmus festlegen. Ein Token mit einem anderen alg wird dann abgelehnt, wobei beide Namen angezeigt werden.

Ein Token mit alg none enthält keine Signatur, daher gibt es nichts zu überprüfen und jeder könnte es erstellt haben. Solche Tokens zu akzeptieren, ist eine bekannte Schwachstelle in JWT-Bibliotheken. Der Verifier meldet dies als Fehler statt als gültiges Ergebnis.

Ein Token gilt als abgelaufen, wenn exp auf oder vor der aktuellen Zeit liegt, und als noch nicht gültig, wenn nbf nach der aktuellen Zeit liegt. Die Uhrzeittoleranz von 0 bis 3600 Sekunden erweitert beide Prüfungen, um Zeitabweichungen zwischen Servern auszugleichen. Vorhandene Claims, die keine Zahlen sind, machen das Token ungültig.

Das Token wurde nicht mit dem von dir angegebenen Schlüssel signiert, oder sein Header oder Payload wurde nach dem Signieren verändert. Prüfe, ob du den passenden öffentlichen Schlüssel oder das Geheimnis mit exakt den richtigen Zeichen eingefügt hast und ob das Token vollständig kopiert wurde. Der decodierte Header und Payload werden weiterhin angezeigt, damit du sie vergleichen kannst.

HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512 und EdDSA mit Ed25519-Schlüsseln. RSA-Schlüssel müssen mindestens 2048 Bit haben. Verschlüsselte Tokens (JWE) werden nicht entschlüsselt.

Nein. Token und Schlüssel werden nur für diese Überprüfung im Arbeitsspeicher verwendet und niemals protokolliert oder gespeichert. Einen öffentlichen Schlüssel kannst du bedenkenlos weitergeben, aber behandle HMAC-Geheimnisse sorgfältig und rotiere jedes Geheimnis, von dem du vermutest, dass es offengelegt wurde.

Tokens dürfen bis zu 65,536 Zeichen und das Schlüsselfeld bis zu 262,144 Zeichen lang sein, sodass auch große JWKS-Dokumente hineinpassen. Das Token muss aus drei durch Punkte getrennten Base64url-Teilen bestehen, mit einem JSON-Header mit einem alg-Member und einem JSON-Objekt als Payload.