Acquérir une compréhension claire des fondamentaux du JSON Web Token (JWT) en 5 minutes.
Le JSON Web Token (JWT) est largement utilisé dans les applications web modernes et les normes ouvertes telles que OpenID Connect, facilitant l'authentification et l'autorisation. Bien que l'officiel RFC 7519 serve de référence essentielle, il sera difficile pour les débutants de le comprendre. Dans cet article, nous nous concentrerons sur les concepts de base de JWT et les présenterons dans un langage simple avec des exemples.
De nos jours, il est assez courant d'utiliser JSON pour échanger des données entre deux parties. Considérez un objet JSON représentant un utilisateur :
subest l'abréviation de "subject", qui est une revendication standard dans OpenID Connect pour représenter l'identifiant de l'utilisateur (ID d'utilisateur).
Comment pouvons-nous garantir l'intégrité de cet objet JSON ? En d'autres termes, comment pouvons-nous nous assurer que les données ne sont pas altérées pendant la transmission ? Une solution courante consiste à utiliser des signatures numériques. Par exemple, nous pouvons utiliser la cryptographie à clé publique: le serveur signe l'objet JSON avec sa clé privée, et le client peut vérifier la signature avec la clé publique du serveur.
En un mot, JWT offre une approche normalisée pour représenter l'objet JSON et sa signature.
Comme il existe de nombreux algorithmes pour créer des signatures numériques, il est nécessaire de spécifier l'algorithme utilisé pour la signature JWT. Cela est accompli en construisant un objet JSON :
algest l'abréviation de "algorithme", ettypest l'abréviation de "type".
Généralement, typ est défini sur JWT en majuscules. Pour notre exemple, alg est HS256, qui signifie HMAC-SHA256 (nous l'expliquerons bientôt), et indique que nous utilisons cet algorithme pour créer la signature.
Maintenant, nous avons tous les ingrédients pour un JWT :
Cependant, certains caractères comme les espaces et les sauts de ligne ne sont pas compatibles avec la transmission sur le réseau. Par conséquent, l'en-tête et la charge utile doivent être encodés en Base64URL. Le JWT typique ressemble à ceci :
Le
.sert de délimiteur.
Assemblons tout cela et créons un JWT :
JSON : {"alg":"HS256","typ":"JWT"}
Encodé en Base64URL : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
JSON : {"sub":"foo","name":"John Doe"}
Encodé en Base64URL : eyJzdWIiOiJmb28iLCJuYW1lIjoiSm9obiBEb2UifQ
Dans HMAC-SHA256, la signature est créée avec un secret :
Par exemple, avec le secret some-great-secret, la signature devient : XM-XSs2Lmp76IcTQ7tVdFcZzN4W_WcoKMNANp925Q9g.
Le JWT final est :
Ce JWT valide peut être vérifié par toute partie possédant le secret.
Comme mentionné précédemment, il existe divers algorithmes pour créer des signatures numériques. Nous avons utilisé HS256 comme exemple, mais il peut ne pas être assez fort car le secret doit être partagé entre les parties (par exemple, le client et le serveur).
Dans les scénarios réels, les clients peuvent inclure des applications publiques comme les applications React qui ne peuvent pas garder le secret en sécurité. En conséquence, l'approche préférée consiste à utiliser la cryptographie à clé publique (c'est-à-dire la cryptographie asymétrique) pour signer le JWT. Commençons par l'algorithme le plus populaire : RSA.
RSA, un algorithme asymétrique, utilise une paire de clés : une clé publique et une clé privée. La clé publique est utilisée pour vérifier la signature, tandis que la clé privée est utilisée pour la signature.
L'en-tête JSON pour RSA ressemble à ceci :
RS256signifie RSA-SHA256, ce qui signifie que la signature est créée avec l'algorithme RSA et la fonction de hachage SHA256. Vous pouvez également utiliserRS384etRS512pour créer des signatures avec les fonctions de hachage SHA384 et SHA512, respectivement.
La signature est créée avec la clé privée :
Encore une fois, nous pouvons assembler ces parties pour créer un JWT, et le JWT final ressemble à ceci :
Maintenant, le client peut vérifier la signature sans connaître la clé privée.
Bien que le RSA soit largement adopté, il souffre de tailles de signature plus grandes, dépassant parfois la taille combinée de l'en-tête et de la charge utile. L'algorithme de signature numérique à courbe elliptique (ECDSA) est un autre algorithme asymétrique qui peut créer des signatures plus compactes et est plus performant.
Pour générer une clé privée pour ECDSA, nous devons choisir une courbe. Cela dépasse le cadre de cet article, mais vous pouvez trouver plus d'informations ici.
L'en-tête JSON pour ECDSA ressemble à ceci :
ES256signifie ECDSA-SHA256, ce qui signifie que la signature est créée avec l'algorithme ECDSA et la fonction de hachage SHA256. Vous pouvez également utiliserES384etES512pour créer des signatures avec les fonctions de hachage SHA384 et SHA512, respectivement.
La signature est créée avec la clé privée :
Le JWT final conserve la même structure que le RSA mais avec une signature nettement plus courte :
La vérification d'un JWT est simple car c'est le processus inverse de la création d'un JWT :
..Il existe de nombreuses bibliothèques qui sont disponibles pour aider à la vérification du JWT, comme jose pour Node.js et les navigateurs web.
Dans cet article, nous avons brièvement expliqué les concepts de base du JWT, avec un aperçu de comment le créer et le vérifier. De nombreux détails restent à explorer, et nous les aborderons dans des articles futurs.
Logto exploite des normes ouvertes comme JWT et OpenID Connect pour sécuriser vos applications et API avec des flux de travail simplifiés pour chaque développeur. Si vous êtes intéressé, vous pouvez l'essayer gratuitement (aucune carte de crédit requise).