jose deckt die gesamte JOSE-Familie ab – signierte und verschlüsselte Tokens, Import und Export von JWKs, lokale und entfernte JWK-Sets – und bietet dafür eine einzige API in jeder JavaScript-Laufzeitumgebung. Seit Version 6 läuft die gesamte Kryptografie über WebCrypto. Schlüssel sind deshalb Objekte vom Typ CryptoKey (Instanzen von KeyObject aus Node.js werden weiterhin akzeptiert), und die Bibliothek erbt die Kurvenliste von WebCrypto: ES256, ES384 und ES512, EdDSA und Ed25519 sowie in 6.2.13 die ML-DSA-Algorithmen, sofern die Laufzeitumgebung sie bereitstellt. ES256K und Ed448 werden mit ERR_JOSE_NOT_SUPPORTED abgelehnt.
Wo es darauf ankommt, sind die Standardeinstellungen streng. jwtVerify() akzeptiert alg: none nie – unsignierte Tokens lassen sich nur über die separate Klasse UnsecuredJWT lesen –, und ein Schlüssel ist an eine Algorithmusfamilie gebunden: Ein HS256-Token, geprüft mit einem öffentlichen Schlüssel vom Typ EC, oder ein RS256-Token mit einem EC-Schlüssel scheitert mit einem TypeError, statt die Prüfung zu bestehen. ES256 lehnt außerdem einen P-384-Schlüssel ab. Übergib algorithms trotzdem: Bei einem Schlüsselsatz mit mehreren Schlüsseltypen verhindert erst diese Option, dass ein Aussteller stillschweigend den Algorithmus wechselt.
Zwei Standardeinstellungen fallen gegensätzlich aus. clockTolerance ist null und damit streng, exp dagegen ist optional und damit großzügig: Ein Token ohne Ablaufzeit besteht die Prüfung, sofern du den Claim nicht in requiredClaims aufführst, wie es das Beispiel tut. Ein JWS, dessen ECDSA-Signatur als DER ankommt – typisch, wenn ein Token von Hand mit einem Cloud-KMS oder openssl dgst zusammengesetzt wird –, scheitert mit der allgemeinen Meldung signature verification failed, und nichts deutet auf die Kodierung hin; der JWT-Debugger zeigt die Länge der Signatur auf einen Blick, und der Konverter DER ⇄ Raw behebt das Problem.
Der Schlüsselimport ist explizit: importSPKI und importPKCS8 nehmen PEM-Strings entgegen – DER-Bytes werden mit "spki" must be SPKI formatted string abgelehnt –, importX509 nimmt ein PEM-Zertifikat und importJWK einen JWK. Die SEC1-Dateien EC PRIVATE KEY, die OpenSSL standardmäßig schreibt, lehnt importPKCS8 ab; konvertiere sie zuerst in PKCS#8, zum Beispiel mit dem JWK-Konverter.
Um Tokens eines Identity Providers zu prüfen, nutze createRemoteJWKSet mit dem jwks_uri des Anbieters: Die Funktion speichert Schlüssel zwischen, lädt sie bei einem unbekannten kid neu und drosselt diese erneuten Abrufe per Rate Limit. Prüfe mit dem JWKS-Checker, was der Anbieter tatsächlich veröffentlicht.