JWT (JSON Web Token) : Qu'est-ce que c'est ?

Qu'est-ce que le JWT (JSON Web Token) ?

Le JSON Web Token, abrégé JWT (prononcé « jot »), est un standard ouvert défini par la RFC 7519 qui permet de créer des tokens d'accès compacts et sécurisés. Un JWT est une chaîne de caractères encodée en Base64URL composée de trois parties séparées par des points : l'en-tête (header), la charge utile (payload) et la signature. L'en-tête spécifie l'algorithme de signature (HS256, RS256), le payload contient les revendications (claims) comme l'identité de l'utilisateur et les permissions, et la signature garantit l'intégrité du token.

Contrairement à l'authentification par session classique où le serveur stocke l'état de connexion, le JWT est autoportant (self-contained) : toutes les informations nécessaires à la vérification sont contenues dans le token lui-même. Le serveur n'a qu'à vérifier la validité de la signature avec sa clé secrète, sans interroger une base de données de sessions. Cette propriété rend le JWT particulièrement adapté aux architectures distribuées, aux microservices et aux API REST consommées par des applications mobiles ou des clients JavaScript.

Le JWT s'est imposé comme le standard de facto pour l'authentification des API modernes. Dans l'écosystème Django, la bibliothèque djangorestframework-simplejwt fournit une intégration complète avec Django REST Framework, offrant la génération, le rafraîchissement et la vérification de tokens JWT.

Pourquoi le JWT est important

L'adoption du JWT transforme la manière dont les applications modernes gèrent l'authentification et l'autorisation. Ses caractéristiques uniques répondent aux défis des architectures contemporaines.

• Architecture stateless : le JWT élimine la nécessité de stocker les sessions côté serveur, simplifiant la scalabilité horizontale. Chaque instance de l'application peut vérifier un token indépendamment.
• Interopérabilité cross-domaine : contrairement aux cookies de session limités à un domaine, le JWT peut être transmis entre différents services et domaines via l'en-tête Authorization, facilitant les architectures microservices.
• Support mobile natif : les applications mobiles et les clients API n'ont pas accès aux cookies du navigateur. Le JWT offre un mécanisme d'authentification universel qui fonctionne identiquement sur toutes les plateformes.
• Performance : la vérification d'un JWT ne nécessite qu'une opération cryptographique locale (vérification de signature), sans aller-retour vers la base de données ou un service de sessions centralisé.
• Claims personnalisées : le payload du JWT peut contenir des informations métier (rôle, permissions, organisation) directement accessibles par l'application sans requête supplémentaire.

Comment ça fonctionne

Le flux d'authentification JWT se déroule en plusieurs étapes. L'utilisateur s'authentifie d'abord avec ses identifiants (email et mot de passe) auprès d'un endpoint de connexion. Le serveur vérifie les identifiants, puis génère une paire de tokens : un access token (durée de vie courte, typiquement 15 à 60 minutes) et un refresh token (durée de vie longue, typiquement 7 à 30 jours). Le client stocke ces tokens (localStorage, cookie HttpOnly, ou mémoire) et inclut l'access token dans l'en-tête Authorization de chaque requête API : Authorization: Bearer eyJhbGciOiJIUzI1....

Lorsque l'access token expire, le client utilise le refresh token pour en obtenir un nouveau sans redemander les identifiants. Le serveur vérifie le refresh token, et s'il est valide, émet un nouvel access token. Ce mécanisme offre un compromis entre sécurité (tokens courte durée) et expérience utilisateur (pas de reconnexion fréquente).

La sécurité du JWT repose sur la signature cryptographique. Avec l'algorithme symétrique HS256, le serveur utilise une clé secrète unique pour signer et vérifier les tokens. Avec l'algorithme asymétrique RS256, une clé privée signe les tokens et une clé publique les vérifie, ce qui est idéal dans les architectures distribuées où les services de vérification n'ont pas besoin d'accéder à la clé de signature.

Exemple concret

Chez KERN-IT, nous utilisons le JWT dans nos applications qui exposent des API REST consommées par des clients multiples. Pour une plateforme IoT, les données collectées par les Raspberry Pi sont transmises via MQTT vers notre backend Python (Flask ou Django selon le projet), tandis que les tableaux de bord web et les applications mobiles accèdent aux données via une API REST authentifiée par JWT. Chaque Raspberry Pi possède un token de service longue durée, tandis que les utilisateurs humains obtiennent des access tokens courte durée via le flux de connexion classique.

Nous avons configuré djangorestframework-simplejwt avec des access tokens de 30 minutes et des refresh tokens de 14 jours. Les claims personnalisées incluent le rôle de l'utilisateur et les identifiants des projets auxquels il a accès, permettant un contrôle d'accès fin directement depuis le token sans requête supplémentaire vers la base de données. Le refresh token est stocké dans un cookie HttpOnly pour empêcher son accès par du JavaScript malveillant (protection XSS).

Mise en oeuvre

1. Installer djangorestframework-simplejwt : ajoutez la bibliothèque à votre projet Django et configurez-la dans REST_FRAMEWORK avec DEFAULT_AUTHENTICATION_CLASSES.
2. Configurer les durées de vie : définissez des durées appropriées pour l'access token (15-60 min) et le refresh token (7-30 jours) selon votre niveau de sécurité requis.
3. Ajouter des claims personnalisées : étendez le serializer de token pour inclure les informations métier utiles (rôle, permissions, tenant) dans le payload du JWT.
4. Sécuriser le stockage côté client : stockez le refresh token dans un cookie HttpOnly/Secure/SameSite et l'access token en mémoire (variable JavaScript) pour minimiser la surface d'attaque XSS.
5. Implémenter la rotation des refresh tokens : activez ROTATE_REFRESH_TOKENS = True et BLACKLIST_AFTER_ROTATION = True pour qu'un refresh token ne soit utilisable qu'une seule fois.
6. Mettre en place la révocation : configurez une blacklist de tokens (via simplejwt.token_blacklist) pour pouvoir invalider des tokens en cas de déconnexion ou de compromission.

Technologies et outils associés

• djangorestframework-simplejwt : bibliothèque de référence pour l'intégration JWT avec Django REST Framework, supportant access/refresh tokens et blacklisting.
• Django REST Framework : toolkit de construction d'API REST pour Django, avec support natif de l'authentification JWT.
• PyJWT : bibliothèque Python bas niveau pour l'encodage et le décodage de tokens JWT.
• OAuth 2.0 : protocole d'autorisation qui utilise souvent le JWT comme format de token d'accès.
• jwt.io : outil en ligne pour décoder, vérifier et déboguer les tokens JWT pendant le développement.
• Keycloak / Auth0 : serveurs d'identité qui émettent et gèrent des JWT pour l'authentification centralisée (SSO).

Conclusion

Le JWT s'est imposé comme le standard d'authentification pour les API REST modernes grâce à sa nature stateless, sa compacité et son interopérabilité. Associé à Django REST Framework via djangorestframework-simplejwt, il offre une solution d'authentification robuste et performante pour les applications distribuées. Chez KERN-IT, nous utilisons le JWT dans nos plateformes IoT et nos applications métier pour sécuriser les communications entre les capteurs Raspberry Pi, les backends Django et les interfaces web, en appliquant les bonnes pratiques de rotation des tokens et de stockage sécurisé conformes aux recommandations OWASP.