Nimbus cubre JWS, JWE, JWK y JWT en dos capas: objetos de bajo nivel (SignedJWT, ECDSASigner, MACVerifier) y el DefaultJWTProcessor, que reúne la selección de claves, la comprobación de la firma y la de los claims. El servidor de recursos de Spring Security se basa en él, así que sus valores predeterminados son los que aplica la mayoría de las API de Spring.
Con el procesador, el JWSVerificationKeySelector es la lista de algoritmos permitidos: configurado para ES256, rechazó un token RS256 y un token HS256 con el texto PEM de la clave EC como clave, con Another algorithm expected, or no matching key(s) found, y sin ningún selector lo rechaza todo. Los tokens sin firmar se rechazan (Unsecured (plain) JWTs are rejected, extend class to handle). La API de bajo nivel no tiene esa protección —un MACVerifier construido a partir del texto PEM verificó ese token HS256 falsificado—, así que el código que elige un verificador según el encabezado del token reproduce el clásico error de confusión de algoritmos. Usa el procesador, como hace el ejemplo.
DefaultJWTClaimsVerifier admite por defecto 60 segundos de desfase de reloj, y exp es opcional salvo que figure como claim obligatorio; el ejemplo exige sub y exp y fija el emisor. ES256 rechaza una clave P-384 (The ES256 algorithm is not allowed or supported by the JWS signer), y una firma codificada en DER simplemente no se verifica; comprueba la longitud de la firma con el decodificador de JWT.
La versión 10.10 superó la prueba de ida y vuelta con las familias HS, RS, PS y ES, además de EdDSA y el nombre más reciente Ed25519. Ed25519 necesita Google Tink en el classpath: sin él, la operación de firma falló con NoClassDefFoundError: com/google/crypto/tink/subtle/Ed25519Sign$KeyPair. ES256K necesita un proveedor con secp256k1, como Bouncy Castle, porque el JDK no tiene ninguno.
Para comprobar qué publica un proveedor de identidad, usa el comprobador de JWKS; para los tokens cifrados, el inspector de JWE.