jose cubre toda la familia JOSE —tokens firmados y cifrados, importación y exportación de JWK, conjuntos de JWK locales y remotos— con una sola API en todos los entornos de ejecución de JavaScript. Desde la versión 6 hace toda la criptografía a través de WebCrypto, así que las claves son objetos CryptoKey (se siguen aceptando instancias KeyObject de Node.js), y la biblioteca hereda la lista de curvas de WebCrypto: ES256, ES384 y ES512, EdDSA y Ed25519, y en la 6.2.13 los algoritmos ML-DSA allí donde el entorno de ejecución los ofrece. ES256K y Ed448 se rechazan con ERR_JOSE_NOT_SUPPORTED.
Sus valores predeterminados son estrictos donde importa. jwtVerify() nunca acepta alg: none —los tokens sin firmar solo se pueden leer con la clase aparte UnsecuredJWT— y cada clave está ligada a una familia de algoritmos, así que un token HS256 presentado con una clave pública EC, o un token RS256 con una clave EC, falla con un TypeError en lugar de verificarse. ES256 también rechaza una clave P-384. Pasa algorithms de todos modos: con un conjunto de claves que contiene varios tipos de clave, es lo que impide que un emisor cambie de algoritmo en silencio.
Dos valores predeterminados tiran en sentidos opuestos. clockTolerance es cero, lo que es estricto, y exp es opcional, lo que no lo es: un token sin caducidad se verifica salvo que la incluyas en requiredClaims, como hace el ejemplo. Un JWS cuya firma ECDSA llegó en DER —algo habitual cuando un token se arma a mano con un KMS en la nube o con openssl dgst— falla con el error genérico signature verification failed, sin nada que apunte a la codificación; el decodificador de JWT muestra la longitud de la firma de un vistazo y el conversor DER ⇄ en bruto la corrige.
La importación de claves es explícita: importSPKI e importPKCS8 reciben cadenas PEM —los bytes DER se rechazan con "spki" must be SPKI formatted string—, importX509 recibe un certificado PEM e importJWK, una JWK. importPKCS8 rechaza los archivos SEC1 EC PRIVATE KEY que OpenSSL escribe por defecto; conviértelos antes a PKCS#8, por ejemplo con el conversor de JWK.
Para verificar tokens de un proveedor de identidad, usa createRemoteJWKSet con el jwks_uri del proveedor: guarda las claves en caché, vuelve a descargarlas ante un kid desconocido y aplica un límite de frecuencia a esas descargas. Comprueba qué publica realmente el proveedor con el comprobador de JWKS.