lcobucci/jwt sépare l’analyse, la signature et la validation : une Configuration contient le signataire et les clés, parser()->parse() lit un jeton sans rien contrôler, et validator()->assert() applique les contraintes que vous passez. Appeler assert() sans contrainte lève NoConstraintsGiven, ce qui rend difficile d’écrire par accident une validation qui ne contrôle rien.
SignedWith fixe le signataire et la clé : un jeton RS256 et un jeton HS256 forgé avec le texte PEM de la clé EC ont tous deux échoué avec Token signer mismatch. Les jetons non signés ne peuvent même pas être analysés (The JWT string is missing the Signature part). Les tailles de clé sont imposées dès la signature – ES256 a refusé une clé P-384 (The length of the provided key is different than 256 bits) et HS256 une clé de 40 bits –, ce qui empêche tout simplement de produire des jetons mal formés.
Les contrôles temporels sont eux aussi des contraintes et ne s’exécutent donc que s’ils sont listés : un jeton expiré depuis une heure a passé SignedWith seul. LooseValidAt contrôle exp, nbf et iat lorsqu’ils sont présents et a accepté un jeton sans exp ; StrictValidAt exige les trois (un jeton sans iat a échoué avec "Issued At" claim missing, et un jeton avec iat et exp mais sans nbf, avec "Not Before" claim missing). Les deux acceptent un intervalle de tolérance facultatif, nul par défaut. L’exemple définit les trois claims et vérifie la signature, l’émetteur et la validité stricte en un seul appel.
La 5.6.1 prend en charge HS, RS et ES en 256/384/512 ainsi qu’EdDSA ; il n’existe ni signataire PS*, ni ES256K, si bien que les jetons d’émetteurs qui utilisent RSA-PSS nécessitent web-token. Les signatures ES256 font 64 octets en r‖s brut, et une signature DER échoue avec Token signature mismatch ; le débogueur JWT montre quel encodage contient un jeton.