Tutoriel JWT : Découverte du JWT

Nous allons découvrir aujourd'hui le principe du standard JWT (Json Web Token).

Qu'est-ce que le JWT ?

Un token JWT se compose de 3 chaines de caractères séparées par un ".".

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

• La première partie, l'en-tête, est un JSON encodé en base64 qui décrit le type de token et l'algorithme utilisé pour la signature.
• La seconde partie, le payload, est aussi un JSON encodé en base64 qui contient les informations à transmettre. Ce JSON peut contenir des clefs prédéfinies (appellées claims) qui permettent de donner des informations supplémentaires sur le token (comme la date d'expiration, la cible, le sujet...)
• La dernière partie, la signature, est la partie la plus importante du token JWT car elle permet de s'assurer de l'authenticité du token. Cette signature est générée à partir des 2 premières clefs avec un algorithme particulier (HS256 par exemple avec une clef secrète).

Quel avantage ?

Pour comprendre l'intérêt de ce standard il faut commencer par comprendre le problème avec le système de token "classique" (OAuth, Bearer...)

Lorsqu'un utilisateur se connecte à notre application, on génère et on associe un token à la session. Ce token sera utilisé par les autres composants de notre application et devra être vérifié par le serveur qui l'a généré. Par exemple, si le serveur de websocket a besoin de récupérer des informations utilisateur, il devra interroger le serveur d'authentification pour obtenir les informations associées au token reçu. Cette architecture présente donc comme principale faiblesse de centraliser la partie vérification sur le serveur d'authentification, ce qui peut poser des problèmes en terme de charge / performance.

Le JWT permet de remédier à ce problème de centralisation :

• Il n'est pas nécessaire de faire appel à une autorité extérieure pour obtenir les informations associées au token, un simple base64decode du payload suffit.
• La vérification de l'authenticité d'un token peut se faire de manière autonome, il suffit de connaitre la clef secrète (ou d'avoir la clef publique suivant l'algorithme choisit) pour vérifier que la signature est authentique.

Mais...

En revanche, la simplification de l'architecture a un inconvénient assez important concernant l'invalidation d'une session. Un token JWT émis à un instant t reste valide tant que ça date d'expiration n'est pas dépassée (il est possible de mettre en place un système qui sauvegarde les tokens à expirer prématurément, mais on perd alors une grosse partie de l'interêt du JWT). Il faudra bien prendre en compte cette limitation dans le choix de l'utilisation (ou non) du format JWT.
Il faudra aussi faire attention à ne pas utiliser un payload trop gros, au risque de rendre le JWT trop volumineux.

Cas pratique

Découvrez un cas pratique d'utilisation au travers de la mise en place d'un système de détection de présence.