Jetons d'authentification : types, utilisations et bonnes pratiques

Les jetons d'authentification vérifient l'identité, mais les jetons volés contournent la sécurité. Découvrez JWT, OAuth 2.0, SAML et les jetons matériels, les erreurs courantes et les stratégies de défense. Découvrez comment SentinelOne détecte les attaques basées sur l'identité dans Active Directory et Entra ID.

Qu'est-ce qu'un jeton d'authentification ?

Imaginez ceci : vous vous connectez à votre application d'entreprise à 9 h à New York. Trente minutes plus tard, quelqu'un accède à votre compte depuis Tokyo. Votre mot de passe n'a jamais changé. Votre jeton d'authentification multifacteur (MFA) est resté sur votre bureau. Mais un attaquant vient de franchir votre porte d'entrée à l'aide d'un jeton d'authentification volé.

Les jetons d'authentification sont les badges numériques qui vérifient votre identité dans les systèmes d'entreprise. Ce sont des informations d'identification cryptographiques, de sorte que votre mot de passe ne circule jamais avec la requête. Selon la publication spéciale NIST 800-63B-4, ces jetons constituent la base de l'assurance de l'identité numérique dans les architectures modernes de cybersécurité.

Le scénario ci-dessus n'est pas hypothétique. En 2023, un acteur de la menace a extrait des jetons de session de fichiers de support téléversés vers le système de support client d'Okta et les a utilisés pour détourner les sessions actives de cinq clients. Aucun mot de passe n'a été compromis. Aucune invite MFA n'a reçu de réponse. Un jeton valide a été présenté, et le système a fait exactement ce pour quoi il avait été conçu.

Comprendre comment les jetons fonctionnent, où ils échouent et comment les protéger est ce qui distingue une infrastructure d'authentification qui tient d'une infrastructure qui remet les clés à un attaquant. Cette page couvre ces trois aspects.

Pourquoi les jetons d'authentification sont des cibles de sécurité

Les jetons se situent à l'intersection de votre sécurité des identités et de votre architecture de contrôle d'accès. Lorsque vous vous authentifiez auprès d'un système, vous ne transportez pas vos véritables informations d'identification à chaque requête. À la place, vous recevez un jeton qui indique « cette personne a déjà prouvé qui elle est ».

Volez un jeton et un attaquant contourne entièrement l'authentification. Forgez-en un et il usurpe l'identité d'un utilisateur légitime. Manipulez la manière dont un jeton est validé et il élève ses privilèges sans jamais détenir de compte autorisé.

Le coût d'une telle erreur est bien documenté. Le rapport IBM 2026 Cost of a Data Breach établit le coût moyen mondial d'une violation à 4,99 millions de dollars, un niveau record. Le rapport Verizon 2026 Data Breach Investigations Report (DBIR) a constaté que l'exploitation des vulnérabilités a dépassé les informations d'identification volées comme principal point d'entrée des violations pour la première fois dans les 19 ans d'histoire du rapport. Les informations d'identification occupaient cette place jusqu'à cette année, et un jeton volé est une information d'identification qui a déjà franchi la porte d'entrée.

Pour comprendre ces risques, les équipes de sécurité doivent d'abord reconnaître les différents types de jetons déployés par les organisations et la manière dont chacun présente des considérations de sécurité uniques.

Types de jetons d'authentification

Les organisations déploient différents types de jetons selon leurs exigences de sécurité et leurs cas d'usage.

• JSON Web Tokens (JWT) : Jetons autonomes transportant des revendications encodées dans une structure en en-tête-charge utile-signature. Les JWT permettent une vérification sans état où les serveurs valident les jetons sans consultation de base de données, ce qui les rend idéaux pour les architectures distribuées de microservices.
• Jetons OAuth 2.0 : Le cadre OAuth utilise deux types de jetons qui fonctionnent ensemble. Les jetons d'accès fournissent des informations d'identification de courte durée pour les appels API, tandis que les jetons d'actualisation obtiennent de nouveaux jetons d'accès sans réauthentification. Cette séparation limite les dommages liés au vol de jetons.
• Assertions SAML (Security Assertion Markup Language) : Jetons basés sur XML échangés entre fournisseurs d'identité et fournisseurs de services pour l'authentification unique d'entreprise. SAML reste dominant dans les environnements d'entreprise hérités et les scénarios de fédération B2B.
• Jetons de session : Identifiants générés par le serveur reliant les navigateurs à l'état de session côté serveur. Contrairement aux JWT sans état, les jetons de session nécessitent un stockage côté serveur mais offrent des capacités de révocation immédiate.
• Jetons matériels/FIDO2 : Authentificateurs physiques utilisant la cryptographie à clé publique via les API WebAuthn. Ces jetons offrent une résistance au phishing grâce à la liaison cryptographique à l'origine, garantissant que les informations d'identification ne fonctionnent que sur des sites légitimes.

Bien que chaque type de jeton serve des objectifs différents, ils partagent des éléments architecturaux communs qui déterminent leur posture de sécurité. C'est au niveau de ces composants que le durcissement commence.

Composants essentiels des jetons d'authentification

Les jetons d'authentification contiennent des éléments spécifiques qui déterminent leur posture de sécurité et leurs capacités fonctionnelles.

1. Structure du jeton : Les JWT se composent de trois sections : en-tête (spécifie l'algorithme de signature comme RS256 ou ES256), charge utile (contient les revendications) et signature (garantit l'intégrité cryptographique). Les assertions SAML utilisent des déclarations au format XML conformément aux spécifications OASIS SAML V2.0.
2. Métadonnées du jeton : Les jetons transportent des métadonnées dans leur charge utile. Les horodatages d'expiration (revendication exp) définissent les fenêtres de validité, les revendications d'émission (iat) établissent l'âge du jeton, l'ID JWT (jti) fournit des identifiants uniques pour le suivi de la révocation, et les restrictions d'audience (revendication aud) empêchent la réutilisation du jeton entre services.
3. Entropie de session : Les jetons de session des applications Web nécessitent une entropie minimale générée au moyen de générateurs de nombres pseudo-aléatoires cryptographiquement sécurisés (CSPRNG).
4. Cryptographie des jetons matériels : Les jetons FIDO2 combinent les API navigateur WebAuthn avec le Client to Authenticator Protocol (CTAP). Les clés privées ne quittent jamais l'élément sécurisé, et la liaison cryptographique à l'origine garantit que les informations d'identification ne fonctionnent que sur des sites Web légitimes.

Ces composants se combinent en flux de travail, et c'est dans le flux de travail que la sécurité des jetons se gagne ou se perd. Les sections ci-dessous retracent chaque flux, y compris la manière dont les jetons interagissent avec l'authentification multifacteur.

Fonctionnement des jetons d'authentification

Les jetons d'authentification suivent des flux de travail distincts selon leur type et leur contexte de déploiement.

• Flux d'authentification JWT : Vous soumettez des informations d'identification au serveur d'authentification. Le serveur valide les informations d'identification, génère et signe cryptographiquement un JWT avec des revendications d'expiration, d'audience et d'émetteur, puis le renvoie à votre client. Pour les requêtes suivantes, vous incluez le JWT dans l'en-tête Authorization. Le serveur de ressources valide la signature et vérifie les revendications avant d'accorder l'accès.
• OAuth 2.0 Flux Authorization Code : Vous demandez l'accès à une ressource protégée. Après authentification et consentement, le serveur émet un code d'autorisation que votre application échange contre des jetons d'accès et d'actualisation. Vous utilisez des jetons d'accès de courte durée pour les appels API et échangez des jetons d'actualisation contre de nouveaux jetons d'accès lorsque nécessaire.
• SSO SAML via navigateur Web : Vous tentez d'accéder à une application de fournisseur de services, qui vous redirige vers le fournisseur d'identité. Après authentification, l'IdP génère une assertion SAML signée et la publie vers le fournisseur de services, établissant votre session authentifiée et permettant l'authentification unique sur plusieurs applications.
• Actualisation et rotation des jetons : Les jetons d'accès de courte durée expirent fréquemment, ce qui nécessite des mécanismes d'actualisation. La rotation des jetons génère un nouveau jeton d'actualisation à chaque utilisation, empêchant les attaques par rejeu. Si quelqu'un réutilise un jeton d'actualisation, le système détecte une compromission potentielle et peut révoquer toute la famille de jetons.
• Authentification par jeton matériel : Vous enregistrez votre authentificateur FIDO2 en générant une paire de clés dans l'élément sécurisé de l'appareil. Lors de l'authentification, le service envoie un défi cryptographique que votre authentificateur signe avec la clé privée. Le service vérifie la signature à l'aide de la clé publique enregistrée.

Correctement mis en œuvre, ces flux de travail justifient leur complexité. Voici où cela porte ses fruits.

Cas d'usage des jetons d'authentification

Les jetons d'authentification répondent à des exigences spécifiques de sécurité et d'exploitation dans les environnements d'entreprise.

1. Authentification unique d'entreprise : Les assertions SAML permettent aux employés de s'authentifier une seule fois et d'accéder à des dizaines d'applications sans connexions répétées. Des fournisseurs d'identité comme Okta, Azure AD et Ping Federation émettent des jetons auxquels les fournisseurs de services font confiance, réduisant la fatigue liée aux mots de passe et centralisant la gouvernance des accès.
2. Sécurité des API et des microservices : Les jetons d'accès OAuth 2.0 sécurisent la communication de service à service dans les architectures distribuées. Chaque microservice valide indépendamment les jetons entrants, permettant une évolutivité sans état sans magasins de session partagés.
3. Autorisation tierce : OAuth 2.0 permet des scénarios « Se connecter avec Google » dans lesquels les utilisateurs autorisent des applications à accéder à leurs données sans partager leurs mots de passe. Le serveur d'autorisation émet des jetons à portée limitée qui restreignent ce à quoi les applications peuvent accéder.
4. Sessions d'applications mobiles : Les JWT fournissent une authentification persistante pour les applications mobiles. Les jetons stockés dans le trousseau iOS ou Android KeyStore survivent aux redémarrages de l'application, offrant des expériences utilisateur fluides tout en maintenant la sécurité grâce à un stockage sécurisé spécifique à la plateforme.
5. Authentification machine à machine : Les systèmes automatisés et les appareils IoT utilisent des attributions d'informations d'identification client pour obtenir des jetons d'accès API. Ces jetons authentifient les tâches planifiées, les systèmes de surveillance et les communications des appareils sans interaction humaine.

Le schéma reste le même pour tous. Les jetons remplacent la transmission répétée d'informations d'identification par une revendication que le système récepteur peut vérifier par lui-même.

Principaux avantages des jetons d'authentification

L'authentification basée sur les jetons surpasse la gestion de session traditionnelle sur quatre points :

1. Évolutivité sans état : Les systèmes basés sur les jetons éliminent les exigences de stockage de session côté serveur, permettant des architectures de microservices où les services individuels vérifient indépendamment les informations d'identification sans état partagé.
2. Authentification unique interdomaines : Les assertions SAML 2.0 et OpenID Connect permettent l'authentification unique. Les utilisateurs s'authentifient une seule fois et accèdent à plusieurs applications sans connexions répétées, centralisant la gouvernance de l'authentification.
3. Sécurité des API et Zero Trust : L'authentification de service à service utilisant les informations d'identification client OAuth 2.0 et les JWT signés empêche des services malveillants d'usurper l'identité de services de confiance, ce qui est essentiel pour les architectures zero-trust.
4. Réduction de la surface d'attaque : Une mise en œuvre fondée sur des standards protège contre des attaques spécifiques. Les cookies HttpOnly empêchent l'accès JavaScript. Les attributs SameSite bloquent les attaques Cross-Site Request Forgery (CSRF). Les jetons FIDO2 assurent une résistance au phishing grâce à la liaison cryptographique à l'origine.

Cependant, ces avantages s'accompagnent de compromis. Les mêmes décisions architecturales qui permettent l'évolutivité et la flexibilité introduisent également des défis que les équipes de sécurité doivent traiter.

Défis et limites des jetons d'authentification

L'authentification basée sur les jetons introduit des défis opérationnels et de sécurité spécifiques qui nécessitent une planification architecturale rigoureuse.

1. Complexité de la révocation des jetons : La nature sans état qui apporte des avantages d'évolutivité crée des défis pour la terminaison immédiate de l'accès. Les jetons sans état restent valides jusqu'à expiration, ce qui exige soit des durées de vie courtes qui augmentent la surcharge d'actualisation, soit une infrastructure de liste noire de jetons qui annule les avantages du sans état, soit l'acceptation de fenêtres de latence de révocation.
2. Compromis de gestion de la durée de vie des jetons : Des durées de vie courtes pour les jetons d'accès limitent les dommages potentiels en cas de compromission mais nécessitent des échanges constants de jetons d'actualisation. Des durées de vie longues améliorent l'expérience utilisateur mais créent des fenêtres d'exposition plus importantes si les jetons sont volés.
3. Stockage sécurisé des jetons sur toutes les plateformes : Tout script exécuté dans la page peut lire localStorage et sessionStorage, de sorte qu'une seule faille Cross-Site Scripting (XSS) transforme l'un ou l'autre en liste de jetons valides. L'approche hybride largement adoptée stocke les jetons d'actualisation dans des cookies HttpOnly, conserve les jetons d'accès en mémoire et applique des contrôles CSRF sur le point de terminaison d'actualisation. Un jeton d'accès en mémoire reste exposé au vidage mémoire sur un hôte compromis, ce qui relève de la sécurité des endpoints. Les applications mobiles nécessitent un stockage spécifique à la plateforme : le trousseau iOS conserve directement les jetons, tandis qu'Android les chiffre sous une clé conservée dans l'Android Keystore. La communication de serveur à serveur doit relever d'un système de gestion des secrets tel que HashiCorp Vault ou AWS Secrets Manager.
4. Rotation des clés et gestion cryptographique : La rotation des clés dans les environnements de production introduit une complexité de coordination. Les organisations doivent maintenir plusieurs clés de signature valides pendant les fenêtres de rotation, coordonner la rotation entre services distribués et gérer correctement la validation de l'identifiant de clé (kid).

Ces défis de mise en œuvre créent des vulnérabilités spécifiques que les attaquants exploitent activement dans les environnements d'entreprise.

Erreurs courantes de mise en œuvre des jetons d'authentification

La plupart des violations liées aux jetons d'authentification proviennent d'erreurs de mise en œuvre plutôt que de failles cryptographiques. Comprendre ces erreurs courantes aide les équipes de sécurité à prioriser leurs efforts de durcissement.

• Stockage côté client non sécurisé : Le stockage des jetons d'authentification dans localStorage ou sessionStorage du navigateur représente l'une des erreurs de mise en œuvre les plus répandues. Tout code JavaScript s'exécutant dans le contexte de la page peut accéder directement aux jetons d'authentification et les exfiltrer, les rendant immédiatement vulnérables aux attaques XSS.
• Échecs de validation de signature : Le fait de ne pas valider correctement les signatures JWT crée des vulnérabilités exploitables de contournement de l'authentification. Les attaques de confusion d'algorithme manipulent l'en-tête d'algorithme de RS256 (asymétrique) vers HS256 (symétrique), puis signent les jetons en utilisant la clé publique comme secret HMAC. Les systèmes vulnérables acceptent ces jetons modifiés, permettant une élévation de privilèges. Cette vulnérabilité a été documentée dans CVE-2024-54150 avec un score de gravité CVSS 9.1 CRITICAL. Certaines implémentations acceptent des jetons spécifiant « alg: none », traitant effectivement des jetons non signés comme valides.
• Durées de vie excessives des jetons : Définir des durées de vie trop longues pour les jetons crée des risques de sécurité persistants. Les jetons de longue durée offrent aux attaquants des fenêtres d'opportunité prolongées. Une fois compromis via XSS ou des attaques de l'homme du milieu, des jetons avec des durées de vie excessives permettent un accès non autorisé pendant des jours ou des semaines plutôt que des minutes.
• Absence de mécanismes de révocation des jetons : L'absence de capacités de révocation des jetons représente une lacune architecturale importante. La compromission des Primary Refresh Tokens (PRT) utilisés dans des implémentations SSO comme Azure AD s'avère particulièrement problématique. Sans mécanismes de révocation, les organisations ne peuvent pas mettre fin aux sessions compromises en temps réel, les obligeant à s'appuyer sur l'expiration naturelle des jetons.
• Gestion non sécurisée des clés : Les échecs de gestion des clés créent des vulnérabilités systémiques. Des vulnérabilités d'injection SQL dans les mécanismes de récupération des clés peuvent exposer les clés de signature lorsque les applications utilisent des requêtes SQL vulnérables pour récupérer des clés JWT via le paramètre kid. Le stockage d'informations sensibles dans les charges utiles JWT crée une exposition inutile des données, car les revendications JWT sont uniquement encodées en base64 (et non chiffrées), ce qui les rend trivialement lisibles par toute personne ayant accès au jeton.

Ces échecs ont des noms et des dates. En avril 2022, un attaquant a utilisé des jetons OAuth volés à Heroku et Travis CI pour télécharger des dépôts privés de dizaines d'organisations, dont npm. Le vol de jetons de session Okta décrit en haut de cette page a fonctionné de la même manière : des jetons valides, présentés par la mauvaise partie, acceptés sans question.

Chacun de ces échecs est évitable, et les contrôles sont déjà documentés. Une défense en profondeur fondée sur des standards établis comble les lacunes sur lesquelles comptent les attaquants.

Bonnes pratiques pour les jetons d'authentification

La protection des jetons d'authentification nécessite la mise en œuvre de stratégies de défense en profondeur fondées sur des standards de sécurité faisant autorité tels que NIST SP 800-63B-4, OWASP et les spécifications IETF.

• Déployer des cookies HttpOnly et Secure : Combinez des jetons d'actualisation stockés dans des cookies HttpOnly avec des jetons d'accès conservés en mémoire. Définissez l'indicateur HttpOnly pour empêcher l'accès JavaScript au contenu des cookies. Configurez l'indicateur Secure pour garantir une transmission uniquement via des connexions HTTPS. Mettez en œuvre l'attribut SameSite pour la protection CSRF.
• Mettre en œuvre des jetons d'accès de courte durée avec rotation : Configurez les durées de vie des jetons d'accès selon votre tolérance au risque. La rotation des jetons génère un nouveau jeton d'actualisation à chaque utilisation, empêchant les attaques par rejeu. Suivez tous les jetons d'actualisation émis à l'aide de leurs revendications jti et invalidez immédiatement les jetons précédents après une rotation réussie.
• Appliquer une validation stricte des signatures : Rejetez explicitement les jetons avec « alg: none » spécifié dans l'en-tête. Validez que les algorithmes de signature correspondent aux types attendus, empêchant les attaques de confusion RSA/HMAC. Utilisez des requêtes paramétrées pour la récupération des clés afin d'empêcher l'injection SQL.
• Déployer la liaison des jetons : Configurez des politiques d'accès conditionnel pour appliquer la liaison des jetons, en garantissant que les jetons ne peuvent pas fonctionner en dehors de leurs appareils d'origine grâce à l'intégration de Trusted Platform Module (TPM) ou de Secure Enclave.
• Mettre en œuvre une infrastructure de révocation : Créez un suivi des familles de jetons adossé à une base de données à l'aide des revendications jti. Créez des interfaces administratives pour la révocation de session et déployez une fonctionnalité « déconnexion partout » permettant aux utilisateurs de révoquer toutes les sessions lorsqu'ils soupçonnent une compromission.

Même avec ces bonnes pratiques en place, des attaquants sophistiqués continuent de trouver des moyens de compromettre les jetons. Lorsque la prévention ne tient pas, ce qui compte est la rapidité avec laquelle vous voyez l'utilisation abusive et la rapidité avec laquelle vous pouvez agir.

Comment SentinelOne détecte les attaques basées sur l'identité

Singularity™ Platform fournit une détection et une réponse autonomes sur vos endpoints, vos charges de travail cloud et votre infrastructure d'identité. Lors des évaluations MITRE ATT&CK 2024 : Enterprise, SentinelOne a enregistré 100 % de détection avec 88 % d'alertes en moins que la médiane de tous les fournisseurs évalués, ce qui fait la différence entre une file d'alertes que vos analystes peuvent traiter et une file qu'ils abandonnent. Purple AI™ accélère l'investigation elle-même. Les analystes posent des questions en langage naturel et obtiennent en retour des résumés contextuels d'alertes, avec jusqu'à 80 % de chasse aux menaces plus rapide.

Singularity Identity protège Active Directory et Entra ID contre les menaces liées à l'identité. Ses détections se déclenchent sur les attaques d'identifiants qui ciblent directement ces environnements, y compris l'utilisation de tickets Kerberos volés et falsifiés pour le mouvement latéral et l'élévation de privilèges. La technologie Storyline™ reconstitue l'attaque au fur et à mesure qu'elle se déroule et corrèle les événements d'authentification avec le comportement des endpoints. Vous voyez la chaîne complète, pas une seule alerte. Lorsqu'une détection se déclenche, la réponse autonome contient la menace, isole l'hôte et annule les dommages avec une restauration en 1 clic avant que le ransomware n'achève le chiffrement. 

Demandez une démo à SentinelOne pour voir la détection basée sur l'identité fonctionner dans votre propre environnement.

Faire la visite

Bénéficiez d’une protection des identités en temps réel et d’une visibilité de bout en bout sur les environnements hybrides pour détecter les expositions, stopper l’abus d’identifiants et réduire le risque lié à l’identité.

Points clés à retenir

Ce scénario d'attaque depuis Tokyo de l'introduction ? Il se produit lorsqu'un jeton volé contourne l'authentification sans jamais toucher à un mot de passe ni à une invite MFA. Des jetons mal configurés créent une exposition réelle, et les jetons restent malgré tout essentiels. Chaque type a un rôle : les JWT pour les microservices sans état, OAuth 2.0 pour l'autorisation API, SAML pour le SSO d'entreprise et FIDO2 pour une authentification résistante au phishing. Chacun d'eux devient un vecteur d'attaque lorsqu'il est mis en œuvre sans précaution.

La liste des correctifs est courte. Stockez les jetons d'actualisation dans des cookies HttpOnly, conservez les jetons d'accès en mémoire, validez strictement les signatures et effectuez une rotation à chaque actualisation. La plupart des échecs décrits sur cette page correspondent à l'un de ces éléments laissés de côté, plus deux autres qu'il est plus facile de repousser que de construire : l'infrastructure de révocation et la gestion des clés.

Ajoutez XDR et la détection et réponse aux menaces liées à l'identité (ITDR) afin qu'un jeton entre de mauvaises mains apparaisse comme une détection plutôt que comme une constatation d'audit six mois plus tard. CVE-2024-54150 et les huit groupes étatiques suivis dans la mise à jour d'octobre 2024 de MITRE ATT&CK montrent que l'exploitation des jetons est active et actuelle. Les contrôles qui l'arrêtent existent déjà, et c'est à vous de les déployer.

FAQ

Qu'est-ce qu'un jeton d'authentification ?

Un jeton d’authentification est un identifiant cryptographique qui vérifie votre identité auprès des systèmes d’entreprise sans nécessiter la transmission répétée de votre nom d’utilisateur et de votre mot de passe. Lorsque vous vous connectez à une application, le serveur émet un jeton comme preuve d’une authentification réussie. 

Votre appareil présente ce jeton à chaque requête ultérieure, ce qui permet aux serveurs de vérifier votre identité sans seconde connexion. Les formats courants incluent les JSON Web Tokens (JWTs), les jetons OAuth 2.0, les assertions SAML et les jetons FIDO2.

Quelle est la différence entre les jetons d'accès et les jetons d'actualisation ?

Les jetons d’accès fournissent des identifiants de courte durée pour accéder à des ressources protégées, expirant généralement en quelques minutes conformément aux recommandations du NIST. Les jetons d’actualisation permettent d’obtenir de nouveaux jetons d’accès lorsque les jetons actuels expirent sans nécessiter d’authentification répétée, avec une durée de validité généralement de quelques jours à quelques semaines. 

Cette approche à double jeton équilibre la sécurité grâce à la courte durée de vie des jetons d’accès avec l’expérience utilisateur. La rotation des jetons génère un nouveau jeton d’actualisation à chaque utilisation, invalidant le précédent afin d’empêcher les attaques par rejeu.

Comment les attaquants volent-ils les jetons d'authentification ?

Les attaquants volent des jetons via des attaques XSS extrayant des jetons de localStorage, des attaques de l’homme du milieu interceptant la transmission, le vidage de mémoire sur des terminaux compromis, l’exploitation des pipelines CI/CD et le détournement de session CSRF. 

Huit groupes parrainés par des États, dont APT28, APT29, APT41, Kimsuky, MuddyWater, OilRig, Sandworm Team et Turla, ont mis à jour leurs capacités d’attaque de jetons en 2024. La protection nécessite des cookies HttpOnly, une transmission sécurisée via HTTPS, la liaison des jetons aux appareils et une surveillance comportementale qui détecte  des schémas d’utilisation anormaux.

Comment devez-vous stocker les jetons d'authentification dans les applications web ?

Stockez les jetons d'actualisation dans des cookies HttpOnly, Secure, SameSite empêchant l'accès JavaScript et les attaques CSRF. Conservez les jetons d'accès à courte durée de vie en mémoire plutôt que dans localStorage ou sessionStorage, afin d'éviter le vol basé sur XSS. 

Pour les applications mobiles, utilisez iOS Keychain ou Android KeyStore. Pour la communication serveur, utilisez des systèmes de gestion des secrets comme HashiCorp Vault ou AWS Secrets Manager plutôt que des variables d'environnement ou des fichiers de configuration.

Les jetons d'authentification peuvent-ils être chiffrés pour une sécurité supplémentaire ?

Les JWT contiennent des revendications encodées en base64 que toute personne ayant accès au jeton peut lire. Pour les données sensibles, utilisez JWE (JSON Web Encryption), qui fournit le chiffrement de la charge utile via des normes comme RSA-OAEP-256 ou AES-GCM. 

Cependant, une meilleure pratique consiste à ne jamais inclure de données sensibles dans les charges utiles des jetons. Stockez uniquement des identifiants non sensibles comme les ID utilisateur et les rôles. Conservez les attributs sensibles dans des bases de données backend, en les récupérant côté serveur à l'aide des identifiants de jeton.

Qu'est-ce que la liaison de jeton et comment améliore-t-elle la sécurité ?

La liaison de jeton lie cryptographiquement les jetons d’authentification à l’appareil spécifique sur lequel ils ont été émis, empêchant les attaquants de réutiliser des jetons volés sur différents systèmes. Le jeton devient lié au Trusted Platform Module (TPM) ou au Secure Enclave de l’appareil grâce à des preuves cryptographiques. 

Lorsque le jeton est présenté, le serveur vérifie à la fois la signature du jeton et la liaison à l’appareil. Microsoft Conditional Access et des solutions similaires de gestion des  identités en entreprise prennent en charge la liaison de jeton pour les environnements hautement sécurisés.