web-token implémente JWS, JWE, JWK et les jeux de clés JWK sous forme de composants distincts ; web-token/jwt-library les regroupe, et un bundle Symfony les intègre sous forme de services. C’est le choix en PHP lorsqu’il vous faut JWE, la gestion des jeux de clés JWK ou la liste complète des algorithmes : la version 4.2.3 a signé et vérifié avec HS, RS, PS et ES en 256/384/512 ainsi qu’avec EdDSA, y compris PS384/512 et ES512, qui manquent à firebase/php-jwt. Il n’existe pas de classe d’algorithme ES256K ni de classe Ed25519 entièrement spécifiée.
Les algorithmes sont autorisés explicitement : l’AlgorithmManager transmis à JWSVerifier constitue la liste d’autorisation, et un jeton signé avec tout autre algorithme échoue avec The algorithm "RS256" is not supported. none existe en tant que classe d’algorithme, mais n’est accepté que si vous l’ajoutez au gestionnaire. Un jeton HS256 forgé avec le texte PEM de la clé EC a échoué même avec HS256 autorisé, car une JWK EC ne peut pas servir de clé HMAC. ES256 avec une clé P-384 a produit une signature que le propre vérificateur de la bibliothèque a rejetée.
La vérification et le contrôle des claims sont deux étapes distinctes : JWSVerifier::verifyWithKey() a renvoyé true pour un jeton expiré depuis une heure. Exécutez ensuite un ClaimCheckerManager, listez les claims obligatoires (sans cela, exp n’est pas obligatoire) et passez une tolérance de dérive d’horloge à ExpirationTimeChecker, qui exige aussi une horloge PSR-20 depuis la version 4 ; l’exemple montre toute la séquence.
Une signature ES256 est un r‖s brut de 64 octets, et une signature DER fait renvoyer false à verifyWithKey() ; le débogueur JWT montre laquelle des deux un jeton contient. Les clés sont partout des objets JWK ; JWKFactory les construit à partir de PEM, de certificats ou de paramètres de clé, et le générateur de JWKS produit des jeux de clés dans le même format.