L’authentification TBS (Token Based Security) désigne un mécanisme où un jeton cryptographique, généré après vérification d’identité, remplace le couple identifiant-mot de passe pour chaque requête entre un utilisateur et un service. En entreprise, ce principe sert de socle à la plupart des architectures d’accès modernes, du SSO aux API internes. Comprendre son fonctionnement précis permet de choisir les bons protocoles et d’éviter des failles que le simple déploiement d’un outil ne corrige pas.
Fonctionnement technique de l’authentification par jeton TBS
Le processus se décompose en trois étapes. L’utilisateur soumet ses identifiants à un serveur d’authentification. Ce serveur vérifie les données, puis génère un jeton signé numériquement (JWT, SAML ou autre format). Le jeton est ensuite transmis au client, qui le joint à chaque requête ultérieure vers les services autorisés.
A lire en complément : Sécurisation des accès critiques : quelles bonnes pratiques adopter ?
Le serveur de ressources valide la signature du jeton sans recontacter le serveur d’authentification à chaque appel. C’est cette validation locale qui rend le système performant à grande échelle. Le jeton remplace le mot de passe à chaque échange réseau, ce qui limite l’exposition des identifiants.
Un jeton contient trois éléments : un en-tête décrivant l’algorithme de signature, un payload avec les droits de l’utilisateur et une date d’expiration, puis la signature elle-même. Si le payload est altéré, la signature ne correspond plus et la requête est rejetée. Cette mécanique rend la falsification coûteuse pour un attaquant.
A lire également : Auditeur cybersécurité : les étapes pour devenir un expert du secteur
MFA et TBS auth : pourquoi le jeton seul ne suffit pas
Un jeton volé donne accès aux mêmes ressources que l’utilisateur légitime jusqu’à son expiration. C’est la principale limite d’une architecture TBS sans couche supplémentaire. Les attaques par vol de session ou par rejeu de jeton exploitent exactement cette fenêtre.
L’authentification multifacteur (MFA) protège la phase de génération du jeton, pas le jeton lui-même. Associer un facteur biométrique ou une clé physique au moment de l’émission réduit le risque qu’un attaquant obtienne un jeton valide, même s’il dispose du mot de passe.
Depuis 2023, l’Alliance FIDO et le NIST (mise à jour SP 800-63B) poussent les passkeys basées sur le standard FIDO2 comme alternative aux codes SMS. Les passkeys suppriment le mot de passe de la chaîne d’authentification et résistent aux attaques par fatigue MFA, où l’attaquant bombarde l’utilisateur de notifications jusqu’à validation accidentelle.
- Un jeton à durée de vie courte (quelques minutes) limite la fenêtre d’exploitation en cas de vol, mais impose des renouvellements fréquents gérés par un refresh token stocké de façon sécurisée.
- Le binding de jeton au terminal (device binding) empêche l’utilisation du jeton depuis un appareil non enregistré, en liant la signature à une clé matérielle propre au poste.
- La révocation côté serveur, via une liste noire de jetons ou un mécanisme d’introspection, reste nécessaire pour couper l’accès immédiatement en cas d’incident, même si elle ajoute un appel réseau.
Obligations réglementaires européennes sur l’authentification en entreprise
La directive NIS2, dont la transposition dans les États membres devait intervenir au plus tard en octobre 2024, impose aux entités qualifiées d’essentielles ou d’importantes des mesures renforcées de gestion des risques. Parmi ces mesures figurent explicitement des contrôles d’accès forts et une authentification robuste pour les systèmes critiques.
Le règlement DORA, applicable progressivement jusqu’en 2025-2026 dans le secteur financier européen, va plus loin. Il exige des contrôles stricts d’authentification et de gestion des accès pour les systèmes ICT critiques, avec des tests de résilience opérationnelle réguliers.
Pour une entreprise qui déploie une architecture TBS, ces textes ont une conséquence concrète : un jeton sans MFA robuste ne satisfait pas les exigences NIS2 ni DORA. L’audit de conformité vérifiera la chaîne complète, du facteur d’authentification initial jusqu’à la politique d’expiration et de révocation des jetons.
Erreurs fréquentes dans le déploiement TBS auth en entreprise
La première erreur consiste à stocker les jetons dans le localStorage du navigateur. Ce stockage est accessible à tout script JavaScript exécuté sur la page, ce qui le rend vulnérable aux attaques XSS. Un cookie HttpOnly avec l’attribut Secure offre une surface d’attaque réduite.
La deuxième erreur porte sur la durée de vie des jetons. Un jeton d’accès valide plusieurs heures, voire plusieurs jours, transforme chaque vol de session en accès prolongé. Configurer une expiration courte pour le jeton d’accès et un refresh token à usage unique représente un compromis efficace entre sécurité et fluidité.
- Ne pas valider la signature du jeton côté serveur de ressources expose l’application à des jetons falsifiés. Chaque service doit vérifier la signature avec la clé publique du serveur d’authentification.
- Accorder des permissions trop larges dans le payload du jeton (rôle administrateur par défaut, accès à toutes les API) revient à distribuer des clés passe-partout. Le principe du moindre privilège s’applique aussi aux claims du jeton.
- Ignorer la rotation des clés de signature crée un risque systémique : si la clé privée fuit, tous les jetons émis avec cette clé sont compromis. Une rotation trimestrielle avec publication de la nouvelle clé publique limite l’impact.
Supervision et journalisation des événements d’authentification
Un système TBS auth génère des événements exploitables : émission de jeton, échec de validation, tentative de renouvellement avec un refresh token expiré. Centraliser ces logs dans un SIEM permet de détecter des comportements anormaux, comme un même jeton utilisé simultanément depuis deux géolocalisations distinctes.
La corrélation entre les logs d’authentification et les logs applicatifs révèle des schémas d’attaque que ni l’un ni l’autre ne montrerait seul. Un pic de renouvellements de jetons sur un compte unique, combiné à des requêtes API inhabituelles, signale une compromission probable.
Sans journalisation centralisée, un jeton volé peut être exploité pendant toute sa durée de vie sans déclencher d’alerte. La supervision transforme un mécanisme d’authentification passif en dispositif de détection actif.
Le déploiement d’une architecture TBS auth ne se limite pas au choix d’un protocole ou d’un fournisseur. La sécurité réelle dépend de la configuration des jetons, de la robustesse du facteur initial d’authentification et de la capacité à détecter les usages anormaux. Les exigences NIS2 et DORA rendent cette rigueur non optionnelle pour un nombre croissant d’entreprises européennes.
