JWT (JSON Web Token) se compose généralement d'un en-tête + charge utile + signature.
En-tête
Contient les informations de métadonnées sur le JWT.
alg : l'algorithme utilisé pour signer le token.
typ : le type du token, toujours JWT.
{
"alg": "HS256",
"typ": "JWT"
}Vous pouvez trouver d'autres en-têtes, mais les précédents seront toujours présents.
Charge utile
La charge utile contient les revendications du JWT. Les en-têtes standard sont les suivants :
iss : l'émetteur, l'entité qui génère et émet le JWT.
sub: le sujet, l'entité identifiée par ce jeton.
aud: l'audience, le public cible de ce JWT.
exp : l'expiration, l'horodatage au format UNIX après lequel le jeton ne doit pas être accepté.
iat : émis à, spécifie la date à laquelle le token a été émis.
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
Signature
La signature est créée en utilisant l'en-tête encodé, la charge utile encodée, un secret et un algorithme cryptographique.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Les algorithmes suivants sont pris en charge par les composants JWT Client et Server.
Les bibliothèques OpenSSL sont requises pour signer et vérifier le JWT, à une exception près.
Les trois algorithmes ML-DSA sont les algorithmes JOSE post-quantiques de la RFC 9964, et ce sont eux l'exception évoquée ci-dessus : ils sont implémentés en Object Pascal pur dans le pack sgcCrypto, ils signent et valident donc sans aucune bibliothèque OpenSSL présente. La signature est un ML-DSA FIPS 204 en mode pur avec un contexte vide sur l'entrée de signature JWS, portée dans le jeton en base64url. Le signataire est déterministe, la même clé et la même entrée produisent donc toujours la même signature.
Les valeurs d'énumération sont jwtMLDSA44, jwtMLDSA65 et jwtMLDSA87, et l'en-tête alg qu'elles écrivent est ML-DSA-44, ML-DSA-65 et ML-DSA-87. Le client signe avec JWTOptions.Algorithms.MLDSA.PrivateKey, une clé privée PEM PKCS#8, et le serveur valide avec JWTOptions.Algorithms.MLDSA.PublicKey, une clé publique PEM SubjectPublicKeyInfo. L'ensemble de paramètres de la clé doit être celui que nomme l'algorithme : dans le cas contraire, la signature lève une exception et la validation renvoie False.
Les signatures sont volumineuses. Une signature ML-DSA-44 fait 2420 octets contre 64 pour ES256, un jeton grossit donc d'environ 3,2 Ko de base64url, et un jeton ML-DSA-87 d'environ 6,2 Ko. Vérifiez les limites de taille d'en-tête de tout ce que le jeton traverse avant de l'adopter.
Les clés peuvent aussi être transportées sous forme de JSON Web Keys AKP, RFC 9964 sections 3 et 4. sgcMLDSA_ExportPublicJWK et sgcMLDSA_ExportPrivateJWK en écrivent une, sgcMLDSA_ImportJWK lit l'une ou l'autre forme, et sgcMLDSA_ImportJWKAsPEM convertit directement un JWK en les chaînes PEM que lisent les deux composants. Un JWK privé stocke la graine de 32 octets dans priv, la seule forme privée que définit la section 4, une clé privée développée ne peut donc pas être écrite sous forme de JWK. Les quatre fonctions sont déclarées dans sgcHTTP_JWT_MLDSA.
* Les algorithmes ML-DSA nécessitent le pack sgcCrypto. Sans lui, les valeurs d'énumération existent toujours, une fiche enregistrée avec l'une d'elles se charge donc encore, mais la signature lève une exception et tout jeton ML-DSA est rejeté.
TsgcHTTP_JWT_Client: Client JWT qui vous permet d'encoder et de signer un JWT et de l'envoyer comme en-tête d'autorisation dans les protocoles HTTP et WebSocket.
TsgcHTTP_JWT_Server: Serveur JWT qui vous permet de décoder et valider les JWT reçus comme en-tête d'autorisation dans les protocoles HTTP et WebSocket.
* Les composants JWT nécessitent au moins la version Indy 10.6.0.5169 ou l'édition Enterprise de sgcWebSockets.