Skip to main content
(JWT), prononcé « jot », est une norme ouverte (RFC 7519) qui définit une méthode compacte et autonome pour transmettre de l’information de façon sécurisée entre des parties sous la forme d’un objet JSON. Autrement dit, JWT est une norme, ce qui signifie que tous les JWT sont des jetons, mais que tous les jetons ne sont pas des JWT. Comme sa taille est relativement petite, un JWT peut être transmis dans une URL, dans un paramètre POST ou dans un en-tête HTTP, et il se transmet rapidement. Un JWT contient toute l’information requise sur une entité pour éviter d’interroger une base de données plus d’une fois. Le destinataire d’un JWT n’a pas non plus besoin d’interroger un serveur pour valider le jeton.

​
Avantages

  • Compact : les JWTs sont de petite taille, ce qui en fait un excellent choix pour être transmis dans des environnements HTML et HTTP.
JWT encodé comparé à un jeton SAML
  • Sécurisé : les JWTs peuvent utiliser une paire de clés publique/privée sous forme de certificat X.509 pour la signature. Un JWT peut également être signé de façon symétrique à l’aide d’un secret partagé avec l’algorithme HMAC. Pour en savoir plus, consultez Signing Algorithms.
  • Courant : la plupart des langages de programmation prennent en charge les parseurs JSON.

​
Utilisation

  • Authentification : Lorsqu’un utilisateur se connecte avec succès à l’aide de ses identifiants, un jeton d’identification est renvoyé. Selon la spécification OpenID Connect (OIDC), un est toujours un JWT.
  • Autorisation : Une fois qu’un utilisateur s’est connecté avec succès, une application peut demander l’accès à des routes, des services ou des ressources (par exemple, des API) au nom de cet utilisateur. Pour ce faire, l’application doit transmettre un dans chaque requête, qui peut prendre la forme d’un JWT.
  • Échange d’informations : Les JWT constituent un bon moyen de transmettre de l’information de façon sécuritaire entre des parties, car ils peuvent être signés, ce qui permet de s’assurer que les émetteurs sont bien ceux qu’ils prétendent être. De plus, la structure d’un JWT permet de vérifier que le contenu n’a pas été altéré.

​
Sécurité

Les informations contenues dans l’objet JSON peuvent être vérifiées et considérées comme fiables, car elles sont signées numériquement. Bien que les JWT puissent aussi être chiffrés afin d’assurer la confidentialité entre les parties, les JWT émis par Auth0 sont des JSON Web Signatures (JWS), ce qui signifie qu’ils sont signés plutôt que chiffrés. Nous nous concentrerons donc sur les jetons signés, qui permettent de vérifier l’intégrité des claims qu’ils contiennent, tandis que les jetons chiffrés masquent ces claims aux autres parties. En général, les JWT peuvent être signés à l’aide d’un secret (avec l’algorithme HMAC) ou d’une paire de clés publique/privée au moyen de RSA ou d’ECDSA (bien qu’Auth0 ne prenne en charge que HMAC et RSA). Lorsque des jetons sont signés à l’aide de paires de clés publique/privée, la signature certifie également que seule la partie qui détient la clé privée a pu les signer. Avant d’utiliser un JWT reçu, il doit être correctement validé à l’aide de sa signature. Notez qu’un jeton validé avec succès signifie seulement que les informations qu’il contient n’ont pas été modifiées par quelqu’un d’autre. Cela ne veut pas dire que d’autres personnes n’ont pas pu en voir le contenu, qui est stocké en texte clair. Pour cette raison, vous ne devriez jamais stocker d’information sensible dans un JWT et devriez prendre d’autres mesures pour éviter que des JWT soient interceptés, par exemple en les envoyant uniquement en HTTPS, en suivant les bonnes pratiques et en utilisant uniquement des bibliothèques sécurisées et à jour.

​
En savoir plus