--- id: CP-195 slug: jwt-json-web-token-signature-pieges lang: fr title: JSON Web Token (JWT) description: Un JWT est le justificatif que remet une application après votre connexion. Ce que sa signature vérifie, les pièges et les gestes à adopter. canonical_url: https://startbrain.io/cyberpedia/fr/articles/jwt-json-web-token-signature-pieges/ markdown_url: https://startbrain.io/cyberpedia/fr/articles/jwt-json-web-token-signature-pieges.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, « JSON Web Token (JWT) », Cyberpedia, 2026. https://startbrain.io/cyberpedia/fr/articles/jwt-json-web-token-signature-pieges/ (CC BY 4.0) wing: 3 theme: control_access reflex: cr-027 schema: G3 updated: "2026-11-03" translations: fr: https://startbrain.io/cyberpedia/fr/articles/jwt-json-web-token-signature-pieges/ en: https://startbrain.io/cyberpedia/en/articles/jwt-json-web-token-signature-pitfalls/ de: https://startbrain.io/cyberpedia/de/articles/jwt-json-web-token-signatur-fallstricke/ es: https://startbrain.io/cyberpedia/es/articles/jwt-json-web-token-firma-trampas/ sources: - "n": 1 title: Tokens and claims overview - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/security-tokens published: "2025-03-21" accessed: "2026-11-03" - "n": 2 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 3 title: Access tokens in the Microsoft identity platform - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens published: "2025-05-14" accessed: "2026-11-03" - "n": 4 title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 5 title: Authentication - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html accessed: "2026-11-03" - "n": 6 title: Session Management - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html accessed: "2026-11-03" - "n": 7 title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" --- # JSON Web Token (JWT) Après votre connexion à une application d'entreprise, celle-ci vous remet un justificatif numérique que votre navigateur ou votre application présente ensuite à chaque demande. Chez Microsoft, ce justificatif prend la forme d'un JSON Web Token, ou JWT, qui contient des « claims », c'est-à-dire des déclarations sur l'utilisateur ou l'application [1]. Un JWT peut se décoder, par exemple avec le site jwt.ms, et sa signature sert à vérifier l'authenticité du jeton [3]. Cette fiche présente les gestes du salarié et ceux du responsable. ## En 30 secondes - Où ça arrive : avec la plateforme d'identité Microsoft, qui authentifie les utilisateurs et fournit des jetons d'accès, de rafraîchissement et d'identité [1]. - Ce que veut l'attaquant : voler un jeton valide pour agir avec les droits de son propriétaire, sans connaître le mot de passe [2]. - Le réflexe : ne jamais envoyer ni publier un jeton ou une adresse qui en contient un, se déconnecter après usage, et signaler tout comportement anormal. - Si c'est déjà fait : se déconnecter, puis prévenir le service informatique. OWASP rappelle que supprimer un cookie ne suffit pas : « deleting a cookie alone does not invalidate a stolen copy of the session ID », et l'invalidation côté serveur est nécessaire [6]. ## Questions directes ### Qu'est-ce qu'un JWT ? Un JWT comporte trois segments séparés par un point : l'en-tête, le corps et la signature [3]. Le corps contient les claims. La signature sert à évaluer l'authenticité du jeton [3]. ### La signature empêche-t-elle de lire le jeton ? La signature sert à vérifier l'authenticité du jeton. Microsoft indique que les développeurs peuvent décoder un JWT avec un site comme jwt.ms, à des fins de validation et de débogage [3]. Le jeton est sensible et présente un risque de sécurité s'il est mal manipulé [3]. ### Un jeton volé permet-il vraiment d'agir à ma place ? Oui. MITRE décrit des adversaires qui utilisent des jetons d'accès volés pour contourner le processus d'authentification habituel et accéder à des comptes, des informations ou des services. Ces jetons sont utilisés à la place des identifiants de connexion [2]. ### Un jeton volé reste-t-il valable longtemps ? Cela dépend de sa durée de vie. Pour les jetons d'accès Microsoft, la durée par défaut est une valeur aléatoire comprise entre 60 et 90 minutes, 75 minutes en moyenne [3]. Les locataires sans accès conditionnel ont une durée par défaut de deux heures pour des clients comme Microsoft Teams et Microsoft 365 [3]. MITRE note toutefois que l'adversaire peut parfois voler aussi un jeton de rafraîchissement, qui lui permet d'obtenir de nouveaux jetons d'accès sans solliciter l'utilisateur [4]. ## Comment ça marche Le serveur d'autorisation signe le jeton avec une clé privée et publie la clé publique correspondante. Pour valider un jeton, l'application vérifie la signature avec cette clé publique [1]. L'en-tête du JWT indique l'algorithme de signature (claim `alg`) et la clé publique à utiliser (claim `kid`) [3]. Microsoft Entra ID émet des jetons signés avec des algorithmes asymétriques standard, comme RS256 [3]. Le jeton d'accès est transmis à une API comme jeton « bearer » dans l'en-tête Authorization [1]. Comme les jetons sont valides pour une durée limitée, le serveur fournit souvent une paire : un jeton d'accès et un jeton de rafraîchissement, qui sert à renouveler le premier quand il approche de son expiration [1]. Le jeton de rafraîchissement ne donne un nouveau jeton d'accès que si l'utilisateur est toujours autorisé [1]. Dans le cas d'OpenID Connect, l'ID Token est un JWT signé qui permet à une application de vérifier l'identité de l'utilisateur [5]. ## Ce que vous faites En tant que salarié : - N'envoyez jamais un jeton, ni une adresse web qui en contient un, dans un message, un ticket ou un forum. Les identifiants de session placés dans une adresse peuvent se retrouver dans les liens, les journaux, l'historique du navigateur, les favoris, l'en-tête Referer ou les moteurs de recherche [6]. - Déconnectez-vous quand vous avez fini. Une application doit offrir un bouton de déconnexion visible et accessible, pour que l'utilisateur puisse fermer sa session à tout moment [6]. - Ne comptez pas sur la fermeture du navigateur : elle ne permet pas d'imposer une déconnexion de façon fiable, notamment sur mobile [6]. - Signalez un comportement anormal (déconnexions inattendues, actions que vous n'avez pas faites, demande d'autoriser une application inconnue). MITRE décrit des attaquants qui font accorder l'accès à une application malveillante en envoyant un lien d'hameçonnage ciblé [4]. En tant que responsable, à exiger des équipes et des fournisseurs : - La validation de la signature et de l'émetteur par l'application qui reçoit le jeton, avec les valeurs publiées dans le document de découverte OpenID [3]. - Le contrôle de l'audience : une API ne doit accepter que les jetons dont le claim `aud` lui correspond. Accepter un jeton destiné à une autre ressource est un exemple du problème du « confused deputy » [3]. - Des bibliothèques éprouvées plutôt qu'un code maison. Microsoft recommande ses bibliothèques MSAL, qui gèrent l'obtention, le rafraîchissement et la validation des jetons [1]. - Des durées de session limitées. OWASP cite comme plages courantes de délai d'inactivité 2 à 5 minutes pour les applications de forte valeur et 15 à 30 minutes pour celles à faible risque, et demande aussi un délai absolu quelle que soit l'activité [6]. - Un stockage prudent côté navigateur (voir la section suivante). ## Les pièges MITRE indique que les jetons volés sont « used in lieu of login credentials », c'est-à-dire à la place des identifiants de connexion [2]. MITRE note que des cookies de session peuvent contourner certains protocoles d'authentification multifacteur [7]. Plusieurs erreurs d'implémentation reviennent dans les sources. - Le stockage dans le navigateur. OWASP déconseille de stocker jetons d'authentification, identifiants de session, JWT ou jetons de rafraîchissement dans localStorage ou sessionStorage : ces espaces sont accessibles à tout JavaScript exécuté dans l'origine, si bien qu'une seule faille XSS divulgue tous les jetons [6]. OWASP préfère des cookies HttpOnly, Secure et SameSite=Strict, ou un modèle de type Backend-for-Frontend [6]. - Le jeton dans l'adresse. Un identifiant transmis par l'URL peut fuiter et faciliter d'autres attaques, comme la fixation de session [6]. - Une validation faite au mauvais endroit. Selon Microsoft, un client ne doit pas chercher à valider un jeton d'accès : c'est à l'API de le faire, et le client le traite comme une chaîne opaque [3]. - La confiance dans le contenu sans vérifier la signature. Une application qui doit valider un jeton commence par vérifier la signature et l'émetteur [3]. - Des jetons dérobés dans l'infrastructure. Dans des environnements Kubernetes ou des chaînes d'intégration et de déploiement continus, des jetons d'API peuvent être volés si le conteneur ou la chaîne est compromis [4]. - Le vol de session par un script malveillant ou un proxy d'hameçonnage. MITRE cite des logiciels malveillants qui visent les cookies du navigateur, et des outils libres comme Evilginx2 et Muraena qui récupèrent des cookies via un proxy malveillant [7]. Les sources citées ici ne détaillent pas d'autres erreurs de conception fréquemment citées, comme l'algorithme « none », la confusion entre clés ou les secrets faibles. Ce point est à faire vérifier par les équipes de développement avec leurs propres référentiels. ## Sources 1. Microsoft, « Tokens and claims overview - Microsoft identity platform », 21 mars 2025. https://learn.microsoft.com/en-us/entra/identity-platform/security-tokens (consulté le 3 novembre 2026) 2. MITRE ATT&CK, « Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1550/001/ (consulté le 3 novembre 2026) 3. Microsoft, « Access tokens in the Microsoft identity platform - Microsoft identity platform », 14 mai 2025. https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens (consulté le 3 novembre 2026) 4. MITRE ATT&CK, « Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1528/ (consulté le 3 novembre 2026) 5. OWASP, « Authentication - OWASP Cheat Sheet Series ». https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html (consulté le 3 novembre 2026) 6. OWASP, « Session Management - OWASP Cheat Sheet Series ». https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (consulté le 3 novembre 2026) 7. MITRE ATT&CK, « Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1539/ (consulté le 3 novembre 2026) --- Source originale : Cyberpedia, l'encyclopédie publique de cybersécurité et d'IA publiée par Brain. Version canonique : https://startbrain.io/cyberpedia/fr/articles/jwt-json-web-token-signature-pieges/ Vous pouvez reprendre ce texte librement sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), à condition de citer « Brain, Cyberpedia » avec un lien vers l'adresse ci-dessus.