Au-delà du secret : Les risques silencieux des JWT et de l'identité machine 🤖

Dans le paysage numérique de 2026, le périmètre n’a pas simplement disparu ; il a été remplacé par une toile invisible et étendue d’interactions Machine-to-Machine (M2M). Alors que les organisations se tournent vers “Agentic AI” et des microservices hyper-scalés, la menace de sécurité la plus importante ne concerne plus un humain tapant un mot de passe dans une boîte de connexion. Elle implique plutôt un agent IA autonome ou un microservice présentant un JSON Web Token (JWT) à un autre service.

Alors que les JWT sont devenus la “lingua franca” de l’authentification moderne en raison de leur absence d’état et de leur portabilité, ils sont aussi devenus un vecteur silencieux pour des violations catastrophiques. Aujourd’hui, le ratio identité machine/humain est de 82:1. Pour chaque utilisateur humain naviguant dans votre réseau, il y a 82 entités automatisées — conteneurs, scripts, appareils IoT et agents IA — effectuant des actions en leur nom.

Cet article explore les vulnérabilités profondes des implémentations JWT et les risques systémiques des identités machine mal gérées à une époque où les agents IA peuvent penser, planifier et exécuter.

1. L’anatomie de l’identité machine moderne

Avant d’aborder les défaillances, il faut comprendre le changement. La gestion traditionnelle des identités se concentrait sur les interactions Human-to-Machine (H2M), protégées par l’authentification multifactorielle (MFA) et les vérifications biométriques. Cependant, les identités machine n’ont pas de pouces pour la biométrie ni de téléphones pour les codes SMS. Elles se reposent sur des secrets — clés API, certificats, et surtout, JWT.

La montée de l’Agentic AI

En 2026, nous avons dépassé le simple “Chatbot” pour atteindre l’Agentic AI. Ce sont des systèmes autonomes utilisant de grands modèles de langage (LLMs) pour raisonner sur des tâches. Un agent peut décider de :

• Accéder à une base de données via un microservice
• Traiter des données financières en utilisant une API tierce
• Mettre à jour un enregistrement CRM selon ses découvertes

Pour cela, l’agent doit être “usurpé” ou déléguer une autorité. Cette délégation est presque toujours gérée via un JWT. Si ce jeton est compromis, l”agent” devient une menace interne autonome à grande vitesse.

2. Le mirage JWT : pourquoi “sans état” est une épée à double tranchant

L’atout principal des JWT est qu’ils sont sans état. Le serveur n’a pas besoin de stocker une session dans une base de données ; toutes les informations nécessaires pour autoriser la requête sont contenues dans le jeton lui-même.

La faille de la révocation

La plus grande force du JWT est aussi sa faiblesse fatale : une révocation insuffisante du jeton. Parce que le serveur ne vérifie pas un magasin de sessions central, un JWT est valide jusqu’à son expiration.

Le risque : Si le jeton d’un agent IA est volé, un attaquant peut l’utiliser librement jusqu’à ce que la revendication exp (expiration) soit atteinte.

La réalité en 2026 : Dans des microservices à haute vélocité, même une fenêtre de 5 minutes est suffisante pour qu’un script automatisé exfiltre une base de données entière.

Sans mécanisme robuste de liste d’autorisation ou de liste de refus (qui réintroduit l”état” que les développeurs tentaient d’éviter), il n’existe pas de “bouton d’arrêt” pour une identité machine compromise.

3. Flaws fatales dans l’implémentation JWT

Même en 2026, les développeurs continuent de tomber dans des pièges cryptographiques classiques. Des CVEs récents, comme CVE-2025-4692, montrent que même des bibliothèques “endurcies” peuvent être mal configurées.

L’exploitation de l’algorithme “None”

L’en-tête JWT contient un champ alg qui indique comment le jeton a été signé (par ex., HS256, RS256). La spécification permet aussi un algorithme appelé none.

L’exploitation : un attaquant modifie l’en-tête en {"alg": "none"} et supprime la signature. Si le backend est mal configuré, il accepte le jeton comme “déjà vérifié.”

Variation moderne : beaucoup de systèmes en 2026 bloquent now none, mais les attaquants utilisent des bypass de sensibilité à la casse comme nOnE ou NoNe pour passer à travers des filtres rudimentaires.

Confusion d’algorithme (RS256 vs. HS256)

C’est peut-être la faille la plus sophistiquée et courante.

• RS256 utilise une paire asymétrique (clé privée signe, clé publique vérifie)
• HS256 utilise un secret partagé symétrique

Dans une attaque de confusion d’algorithme, un attaquant change l’algorithme du jeton de RS256 à HS256. Il signe ensuite le jeton en utilisant la clé publique du serveur (souvent accessible publiquement). Le serveur, voyant HS256, utilise sa “clé secrète” (qui est en fait sa clé publique) pour vérifier la signature. Les calculs sont corrects, et l’attaquant obtient un accès non autorisé.

4. Les tueurs silencieux : clés de compte de service à longue durée

Alors que les JWT sont généralement courts (minutes ou heures), les clés de compte de service utilisées pour demander ces JWT sont souvent permanentes. Ce sont les “secrets” qui ne dorment jamais.

La persistance des clés obsolètes

Dans une architecture microservices, les développeurs génèrent souvent un fichier clé JSON pour un compte de service afin de permettre à une pipeline CI/CD de déployer du code.

Le problème : ces clés sont souvent codées en dur dans des variables d’environnement, accidentellement commises dans des dépôts GitHub privés, ou laissées dans des logs de build.

Le danger : contrairement à un mot de passe utilisateur, ces clés n’expirent pas. Une clé générée en 2024 pourrait encore être active en 2026, offrant une porte dérobée permanente dans l’infrastructure.

L’agent “sur-permissionné”

Parce que c’est “plus facile” pour le développement, les comptes de service reçoivent souvent des rôles d’Admin ou de Propriétaire. Lorsqu’un Agentic AI utilise un tel compte, son “rayon d’action” est total. Si l’IA est trompée via une Injection de Prompt pour appeler une API spécifique, elle le fait avec toute la puissance de son compte de service sur-permissionné.

5. Agentic AI : la nouvelle frontière du risque JWT

En 2026, le concept de “Surface d’Identité” s’est étendu. Les agents IA ne sont plus de simples outils ; ils sont des pairs dans le réseau.

Exploitation du Prompt vers le jeton

Les attaquants ont évolué, passant de l’attaque du code à celle du raisonnement de l’agent. En empoisonnant les données qu’un agent lit (Retrieval-Augmented Generation ou RAG), un attaquant peut convaincre un agent qu’il doit envoyer son JWT actuel à un “service de journalisation” externe (contrôlé par l’attaquant) pour des “besoins de débogage.”

Communication inter-agent

Les systèmes multi-agents impliquent des agents qui communiquent entre eux. Si l’Agent A (faible sécurité) transmet une requête à l’Agent B (haute sécurité), l’Agent B doit vérifier que l’Agent A est autorisé.

Le piège : si l’Agent B se fie à des “crédentiels mis en cache” ou à des portées héritées sans re-valider l’intention de la requête originale, on observe un problème de “Confused Deputy” à grande vitesse.

6. Renforcer le périmètre : meilleures pratiques pour 2026

Sécuriser l’identité machine nécessite de s’éloigner des secrets statiques vers une sécurité basée sur l’identité, éphémère.

1. Adopter des jetons éphémères à courte durée

Arrêtez d’utiliser des clés de compte de service. Utilisez plutôt l’Identity Workload.

Google Cloud/AWS/Azure : utilisez la fédération d’identité native qui permet à votre code d’échanger un jeton plateforme à courte durée contre un JWT spécifique au service.

Résultat : même si un jeton est volé, il expire en 30 minutes, et il n’y a pas de “clé maître” à voler dans un repo GitHub.

2. Implémenter SPIFFE/SPIRE

Le Secure Production Identity Framework for Everyone (SPIFFE) fournit un moyen pour les services de s’identifier mutuellement sans secrets partagés. Il délivre des SVIDs (SPIFFE Verifiable Identity Documents) à courte durée, qui sont automatiquement renouvelés.

3. Liste blanche stricte d’algorithmes

Ne laissez jamais l’en-tête JWT dicter votre sécurité.

// MAUVAIS : faire confiance à l'en-tête
jwt.verify(token, secret);

// BON : appliquer une politique d'algorithme
jwt.verify(token, publicKey, { algorithms: ['RS256'] });

4. Vérifications continues de révocation

Pour les transactions de haute valeur, utilisez JWT Assertion Grants ou un système centralisé de détection et réponse aux menaces d’identité (ITDR). Cela vous permet de vérifier si un jti (ID JWT) a été signalé comme suspect avant de traiter la requête.

7. Analyse comparative : identité machine vs. identité humaine

Fonctionnalité	Identité humaine (H2M)	Identité machine (M2M/Agentic)
Authentification	Mot de passe, MFA, biométrie	Clés, certificats, JWT
Volume	Faible (milliers)	Extrême (millions)
Vitesse	Vitesse humaine (secondes/minutes)	Vitesse machine (millisecondes)
Cycle de vie	Géré par HR/IAM	Géré par DevOps/Orchestrateur IA
Révocation	Facile (désactiver le compte)	Difficile (tokens sans état)
Risque	Prise de contrôle de compte	Mouvement latéral à l’infrastructure

Conclusion : L’ère des “Privilèges zéro en veille”

Alors que nous avançons dans l’ère de l’Agentic AI, le modèle “Secret” traditionnel est mort. Nous ne pouvons plus nous fier à une chaîne statique pour prouver qui — ou quoi — appelle une API. Les risques liés aux JWT ne sont pas inhérents à la technologie, mais à notre complaisance dans leur mise en œuvre.

En 2026, les organisations les plus sécurisées traitent chaque action machine comme un événement unique, limité dans le temps. En appliquant le principe de Privilèges Zéro en Veille (ZSP) et en passant à une authentification éphémère basée sur l’identité, nous pouvons enfin aller “Au-delà du secret.”

Le “bouton d’arrêt” pour la prochaine génération de menaces IA n’est pas un câble d’alimentation — c’est la capacité à révoquer une identité machine en millisecondes.