Introduction
JSON Web Token (JWT) est un Open Standard (RFC 7519) depuis 2015 qui permet l’échange sécurisé de jetons. Si vous avez l’habitude de concevoir ou de travailler sur des applications web ou mobiles, des logiciels, etc. vous avez certainement déjà entendu parler de ces tokens.
Le but de cet article est de démystifier ces fameux JWT, de vous donner un aperçu concret de ce à quoi ils servent et comment ils fonctionnent. Je vous montrerai également comment ils doivent et ne doivent pas être utilisés, tout en répondant à certaines questions fréquemment posées lorsque l’on débute avec les JWT (entre autre sur le plan de la sécurité).
Après avoir lu ce guide, vous serez capable d’appréhender correctement le fonctionnement des JWT et vous serez en mesure de les intégrer plus facilement dans vos applications, toutes technologies confondues.
Les JWT, à quoi ça sert ?
L’utilisation de JWT Tokens est un moyen de plus en plus populaire d’authentification (et parfois d’autorisation) d’un client auprès d’un serveur.
Comparaison avec une authentification par session
L’authentification par session est un moyen communément utilisé pour gérer des “sessions d’utilisateurs”, c’est pourquoi je vous propose un rapprochement entre session et JWT. Si vous le souhaitez, vous pouvez également passer cette section et vous rendre directement à la suivante.
Si vous êtes habitué à des technologies comme PHP (et ses frameworks), Ruby on Rails, etc. vous êtes certainement à l’aise avec l’authentification par session. Pour résumer, le principe de la gestion d’une authentification par session est la suivante :
- L’utilisateur se connecte à votre site (par exemple avec un couple email/mot de passe)
- Si les informations de connexion sont correctes, le serveur enregistre les informations sur l’utilisateur connecté dans une variable de session (qui est, formellement, un cookie un peu particulier)
- Tout au long de la navigation de l’utilisateur, votre serveur saura le reconnaître grâce à ces informations de session
Dans ce type d’architectures client/serveur, puisque le serveur génère directement le code qui sera transmis au client, il n’y a aucune nécessité d’utiliser un jeton d’authentification : la session sait très bien gérer tout cela.
Néanmoins, dans certaines architectures un poil plus complexe, la gestion de l’authentification par session est impossible ! Prenons l’exemple d’une application mobile qui doit communiquer avec un serveur distant à travers une API.
Si cette application doit gérer la connexion d’utilisateurs à leur espace membre, elle ne pourra pas utiliser de mécanisme d’authentification par session. En effet, il n’existe aucun « lien permanent » entre le client (application mobile) et le serveur. C’est ici qu’interviennent les JWT ! En effet, les JWT constituent une alternative d’authentification basée sur des jetons (en anglais, Token-Based Authentication) au lieu de l’authentification basée sur les sessions.
On dit également que les JWT sont un moyen d'authentification stateless. En effet, tandis qu'une authentification stateful requiert que le serveur connaisse les informations de connexion (i.e. de l'utilisateur connecté), une authentification stateless permet l'échange des informations de connexion via un jeton communiqué entre le client et le serveur (comme c'est le cas avec les JWT).
