Tout savoir sur le jwt

Norme basée sur JSON pour la transmission de revendications entre les parties dans des environnements d’applications Web

JSON Web Token ( JWT , prononciation suggérée , identique au mot « jot » ^[1] ) est une norme Internet proposée pour la création de données avec une signature facultative et/ou un cryptage facultatif dont la charge utile contient JSON qui affirme un certain nombre de revendications. Les jetons sont signés à l’aide d’un secret privé ou d’une clé publique/privée.

Par exemple, un serveur peut générer un jeton avec la revendication « connecté en tant qu’administrateur » et le fournir à un client. Le client peut ensuite utiliser ce jeton pour prouver qu’il est connecté en tant qu’administrateur. Les jetons peuvent être signés par la clé privée d’une partie (généralement celle du serveur) afin que toute partie puisse vérifier par la suite si le jeton est légitime. Si l’autre partie, par une partie appropriée et digne de confiance, est en possession de la clé publique correspondante, ils sont également en mesure de vérifier la légitimité du jeton. Les jetons sont conçus pour être compacts, ^[2] sécurisés pour les URL, ^[3] et utilisables, en particulier dans un contexte de navigateur Web. Les revendications JWT peuvent généralement être utilisées pour transmettre l’identité des utilisateurs authentifiés entre un fournisseur d’identité et un fournisseur de services, ou tout autre type de revendications requis par les processus métier. ^{[4] [5]}

JWT s’appuie sur d’autres normes basées sur JSON : JSON Web Signature et JSON Web Encryption. ^{[1] [6] [7]}

En-tête

de structure

Identifie l’algorithme utilisé pour générer la signature. Dans l’exemple ci-dessous, indique que ce jeton est signé à l’aide de HMAC-SHA256.

Les algorithmes cryptographiques typiques utilisés sont HMAC avec SHA-256 (HS256) et la signature RSA avec SHA-256 (RS256). La RFC 7518 JWA (JSON Web Algorithms) en introduit beaucoup d’autres pour l’authentification et le cryptage. ^[8]

{"alg » :"HS256 »,"typ » :"JWT"}

La charge utile

Contient un ensemble de revendications. La spécification JWT définit sept noms de revendication enregistrés, qui sont les champs standard généralement inclus dans les jetons. ^[1] Les réclamations personnalisées sont généralement également incluses, en fonction de l’objectif du jeton.

Dans cet exemple, il s’agit de la revendication standard Émis à l’heure () et d’une revendication personnalisée ().

{"loggedInAs » :"admin »,"iat » :1422779638}

Signature

en toute sécurité valide le jeton. La signature est calculée en codant l’en-tête et la charge utile à l’aide de l’encodage Base64urlRFC 4648 et en concaténant les deux ensemble avec un séparateur de point. Cette chaîne est ensuite exécutée par l’algorithme cryptographique spécifié dans l’en-tête. Cet exemple utilise HMAC-SHA256 avec un secret partagé (les algorithmes de clé publique sont également définis). L’encodage base64url est similaire à base64, mais utilise des caractères non alphanumériques différents et omet le remplissage.

HMAC_SHA256(secret,base64urlEncoding(header)+'.'+base64urlEncoding(payload))

Les trois parties sont encodées séparément à l'aide de Base64url EncodingRFC 4648, et concaténées à l'aide de points pour produire le JWT :

Les données ci-dessus et le secret de « secretkey » crée le jeton :

(Les chaînes json ci-dessus sont formatées sans sauts de ligne ni espaces, en tableaux d’octets utf-8. Ceci est important car même de légères modifications dans les données affecteront le jeton résultant)

Ce jeton résultant peut être facilement passé en HTML et HTTP. ^[3]

Utilisation

Dans l’authentification, lorsqu’un utilisateur se connecte avec succès, un jeton Web JSON (JWT) est souvent renvoyé. Ce jeton doit être envoyé au client à l’aide d’un mécanisme sécurisé tel qu’un . Il est déconseillé de stocker le JWT localement dans les mécanismes de stockage du navigateur, tels que le stockage local ou de session. Pour les processus non assistés, le client peut également s’authentifier directement en générant et en signant son propre JWT avec un secret pré-partagé et en le transmettant à un service conforme à OAuth comme suit :

Si le client passe une assertion JWT valide, le serveur générera un access_token valide pour effectuer des appels à l’application et le repassera au client :

Lorsque le client souhaite accéder à une route ou à une ressource protégée, l’agent utilisateur doit envoyer le JWT, généralement dans l’en-tête HTTP en utilisant le schéma. Le contenu de l’en-tête peut ressembler à ce qui suit :

Il s’agit d’un mécanisme d’authentification sans état car l’état de l’utilisateur n’est jamais enregistré dans la mémoire du serveur. Les routes protégées du serveur vérifieront la présence d’un JWT valide dans l’en-tête Authorization, et s’il s’agit d’un présent, l’utilisateur sera autorisé à accéder aux ressources protégées. Comme les JWT sont autonomes, toutes les informations nécessaires sont là, ce qui réduit le besoin d’interroger la base de données plusieurs fois.

Champs

La liste des noms de revendications actuellement enregistrés peut être obtenu à partir du registre des réclamations de jeton Web JSON de l’IANA ^[11] .

Implémentations

implémentations JWT existent pour de nombreux langages et frameworks, y compris, mais sans s’y limiter :

Vulnérabilités

Les jetons Web JSON peuvent contenir l’état de la session. Mais si les exigences du projet autorisent l’invalidation de la session avant l’expiration de JWT, les services ne peuvent plus faire confiance aux assertions de jeton par le jeton seul. Pour vérifier que la session stockée dans le jeton n’est pas révoquée, les assertions de jeton doivent être vérifiées par rapport à un magasin de données. Cela rend les jetons non plus sans état, ce qui sape l’avantage principal des JWT. ^[37]

Le consultant en sécurité Tim McLean a signalé des vulnérabilités dans certaines bibliothèques JWT qui utilisaient le champ pour valider incorrectement les jetons, le plus souvent en acceptant un jeton. Bien que ces vulnérabilités aient été corrigées, McLean a suggéré de déprécier complètement le domaine pour éviter une confusion similaire dans l’implémentation. ^[10] Pourtant, de nouvelles vulnérabilités sont toujours trouvées dans la nature, avec quatre CVE déposées au cours de la période 2018-2021 ayant cette cause. ^{[38] [ une meilleure source nécessaire ]}

Avec une conception appropriée, les développeurs peuvent corriger les vulnérabilités des algorithmes en prenant des précautions : ^{[39] [40]}

1. Ne laissez jamais l’en-tête JWT seul piloter la vérification
2. Connaître les algorithmes (éviter de dépendre uniquement du champ)
3. Utilisez une taille

de clé appropriée Plusieurs bibliothèques JWT se sont avérées vulnérables à une attaque à courbe elliptique invalide en 2017. ^[41]

Certains ont fait valoir que les jetons Web JSON sont difficiles à utiliser en toute sécurité en raison des nombreux algorithmes et options de chiffrement différents disponibles dans la norme, et que des normes alternatives devraient être utilisées à la place pour les frontends web ^[42] et les backends. ^[43]

Voir aussi

Références

• RFC 7519
• jwt.io – site web spécialisé sur JWT avec des outils et de la documentation, maintenu par Auth0