Passer au contenu principal
(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. Encore une fois, JWT est une norme, ce qui signifie que tous les JWT sont des jetons, mais que tous les jetons ne sont pas des JWT. En raison de sa taille relativement petite, un JWT peut être envoyé 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é, ce qui évite d’interroger une base de données plus d’une fois. Le destinataire d’un JWT n’a pas non plus à appeler un serveur pour valider le jeton.

Avantages

  • Compacts : les JWT sont de petite taille, ce qui en fait un bon choix pour être transmis dans des environnements HTML et HTTP.
JWT encodé comparé à un jeton SAML
  • Sécurisés : les JWT peuvent utiliser une paire de clés publique/privée sous la forme d’un certificat X.509 pour signer. Un JWT peut aussi être signé de manière symétrique à l’aide d’un secret partagé et de l’algorithme HMAC. Pour en savoir plus, consultez Algorithmes de signature.
  • Courants : la plupart des langages de programmation prennent en charge les analyseurs JSON.

Utilisation

  • Authentification : Lorsqu’un utilisateur se connecte avec succès à l’aide de ses identifiants, un jeton d’identité est renvoyé. Conformément à la spécification OpenID Connect (OIDC), un est toujours un JWT.
  • Autorisation : Une fois l’utilisateur connecté avec succès, une application peut demander l’accès à des routes, des services ou des ressources (par exemple, des API) en son nom. Pour ce faire, l’application doit transmettre un dans chaque requête, lequel peut prendre la forme d’un JWT.
  • Échange d’informations : Les JWT sont un bon moyen de transmettre des informations de façon sécurisée entre des parties, car ils peuvent être signés, ce qui vous permet d’avoir la certitude que les expéditeurs sont bien ceux qu’ils prétendent être. De plus, la structure d’un JWT vous permet de vérifier que son 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 pour assurer la confidentialité entre les parties, les JWT émis par Auth0 sont des JSON Web Signatures (JWS), c’est-à-dire 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, alors que les jetons chiffrés masquent ces claims aux autres parties. En règle générale, 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 faut le valider correctement au moyen 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. C’est pourquoi vous ne devez jamais stocker d’informations sensibles dans un JWT et devriez prendre d’autres mesures pour vous assurer que les JWT ne sont pas interceptés, par exemple en les transmettant uniquement sur HTTPS, en suivant les pratiques exemplaires et en utilisant seulement des bibliothèques sécuritaires et à jour.

En savoir plus