jose4j implémente JWS, JWE, JWK et JWT sur les fournisseurs propres du JDK, avec JsonWebSignature pour la signature et un JwtConsumer construit par JwtConsumerBuilder pour la vérification et le contrôle des claims. La 0.9.7 a fonctionné en aller-retour avec HS, RS, PS et ES en 256/384/512 ainsi qu’avec EdDSA ; ES256K, Ed25519 et Ed448 ne sont pas des noms d’algorithmes reconnus.
Les valeurs par défaut bloquent les deux attaques classiques, mais laissent l’algorithme ouvert. none est refusé ('none' is a blocked algorithm.), sauf si les signatures sont explicitement désactivées, et le type de clé doit correspondre : un jeton RS256 présenté à une clé EC et un jeton HS256 dont la clé est le texte PEM de la clé EC ont tous deux échoué (cannot be used for HMAC verification). Tout autre algorithme que la clé peut exécuter est en revanche accepté : fixez-le donc avec setJwsAlgorithmConstraints(ConstraintType.PERMIT, ...), comme le fait l’exemple. Une HmacKey construite à partir des octets PEM a vérifié le jeton HS256 forgé : les clés doivent provenir de la configuration, jamais de ce qu’affirme le jeton.
Les tailles de clé sont contrôlées : ES256 refuse une clé P-384 (expects a key using P-256 but was P-384) et HS256 a refusé une clé de 16 octets, car la RFC 7518 exige des clés au moins aussi longues que le condensat. Les signatures ES256 sont le r‖s brut de 64 octets ; une signature DER échoue avec Invalid JWS Signature, et le débogueur JWT en montre la longueur.
Les valeurs par défaut des claims tirent en sens contraires : l’absence de tolérance au décalage d’horloge est plus stricte que ce qu’attendent la plupart des équipes, et un exp non obligatoire est plus laxiste. setRequireExpirationTime(), setExpectedIssuer(), setExpectedAudience() et setAllowedClockSkewInSeconds() ont leur place dans tout consommateur qui lit des jetons provenant d’un autre service.
Pour les jetons chiffrés, l’inspecteur JWE montre ce que contient un JWE produit par jose4j.