Authentification multifactorielle, un indispensable !

  • Temps de lecture :20 mins read

Le password est une méthode d’authentification à un compte, service, application qui existe depuis plusieurs décennies. Mais il est jugé obsolète quand des données sensibles sont en jeu. C’est pour cela que différentes méthodes d’authentification ont vu le jour : la A2F, le passwordless, les clés de sécurité, etc…

Nous allons voir ces différentes méthodes par des exemples et leur avantages et inconvénients.

Qu'est-ce que l'authentification ?

L’authentification est un processus pour vérifier une identité d’un individu ou d’un appareil. Cela sert pour accorder l’accès à un système d’informations (SI) sous forme d’une application, un système informatique, un compte, etc…

Elle répond à la question : « Es-tu vraiment qui tu prétends être ? »

Elle a pour objectifs de :

  • Sécuriser l’accès aux données
  • Empêcher les accès non autorisés
  • Servir de base pour d’autres mécanismes : la journalisation, les autorisations, la traçabilité.

Ainsi, un identifiant ou nom d’utilisateur est une donnée demandée dans un formulaire de connexion/inscription qui n’en fait pas partie.

L'authentification multifactorielle

Définition

C’est une méthode d’authentification qui nécessite plusieurs preuves pour autoriser un accès à un système d’information, une application ou un compte.

Elle peut porter différents noms  :

  • MFA : Authentification multifacteurs (pour deux ou plusieurs facteurs)
  • A2F : Authentification à 2 facteurs
  • Double authentification (ou authentification à double facteurs)
  • Validation en deux étapes (ou vérification en deux étapes)

Catégories

Les facteurs sont classifiés en trois groupes :

  • Ce que je sais (knowledge) : Mot de passe, phrase secrète, code PIN… C’est une information mémorisée par l’utilisateur
  • Ce que je possède (possession) : Téléphone, token physique, messagerie, etc… C’est une information détenue par un objet ou un service que l’utilisateur possède.
  • Ce que je suis (inherence) : biométrie. Ce sont les informations biologiques uniques de l’utilisateur (empreinte digitale, reconnaissance faciale, iris, etc…).

L’authentification est dite forte lorsqu’elle utilise au moins deux facteurs distincts pour vérifier l’identité d’un utilisateur.

Méthodes les plus utilisées

Il existe une variété de méthodes pour apporter une preuve d’authentification. Elles varient selon le public visé. Pour le web et les particuliers, voici les 4 plus utilisés :

  • One-Time Password
  • Time-based OTP
  • Notification push
  • Biométrie

One-Time Password (OTP)

Un OTP (One-Time Password) est un code qui ne peut être utilisé qu’une seule fois, souvent valable quelques dizaines de  minutes.

Il remplace le mot de passe statique traditionnel et est une preuve pour l’authentification multifacteurs (MFA).

Fonctionnement

1️⃣ Configuration : À l’activation de la MFA, le système enregistre le numéro de téléphone ou l’adresse mail de l’utilisateur

2️⃣ Connexion : L’utilisateur se connecte au service souhaité. Il entre ses identifiants (ID & mot de passe) sur la page de connexion.

3️⃣ Si les identifiants sont bons, le serveur génère un code à usage unique (souvent un nombre à 6 chiffres), valide quelques minutes.

4️⃣ Il est envoyé par SMS ou par mail selon la configuration

5️⃣ L’utilisateur lit le code sur son téléphone ou sa messagerie, et le saisit dans le formulaire de connexion.

6️⃣ Le serveur vérifie s’il correspond au code  OTP envoyé.

7️⃣ Si le code est correct, l’utilisateur accède au service. Si le code est incorrect ou expiré, l’utilisateur doit en regénérer un nouveau.

Authentification OTP

Avantages / Inconvénients

Avantages Inconvénients

Utilisateur : 

✅ Facile à comprendre et à déployer

✅Aucun besoin d’installer une application supplémentaire

✅ Fonctionne sur tous les téléphones

Développeur / Entreprise :

✅ Coût faible (SMS) ou gratuit (Mail)

✅ Facilité d’intégration dans un système d’authentification

❌ Sécurité faible :

  • Risque de SIM swapping/recycling, Phishing
  • Interception du SMS/Mail
  • SMS/Mail non chiffré
  • Téléphone ou messagerie compromis

❌ Ergonomie limitée

  • Les SMS/Mails peuvent être retardés ou bloqués par les opérateurs
  • Lenteur (attente du message)
  • Ne fonctionne pas sans réseau

❌ Travail du serveur : Le serveur doit stocker un secret ou générer un code aléatoire

Quand utiliser ou éviter l'OTP ?

Utiliser Éviter

✅ Services peu sensibles : newsletters, forums..

✅ Solution temporaire en attendant une méthode mieux sécurisée

❌ Comptes critiques : banque, administration, santé

❌ Sécurité est une priorité absolue : échanges de données personnelles ou sensibles

Time-based OTP (TOTP) : Applications d’authentification

Principe

le TOTP est une forme d’OTP générant un code en fonction  de la valeur actuelle du temps et d’un secret partagé entre le serveur et un authentificator (application).

Fonctionnement

1️⃣ Configuration : Lors de l’inscription ou paramétrage du compte, l’utilisateur scanne un QR code pour récupérer un secret partagé.

2️⃣ Génération du Compteur : L’authentificator génère un code à partir d’un compteur temporel et du secret partagé. Il est tronqué pour obtenir le code à 6 ou 8 chiffres renouvelables toutes les 30 ou 60 secondes.

3️⃣ Authentification : Après la saisies des identifiants (ID + password), le service demande le code de validation. L’utilisateur lance son application d’authentification pour récupérer son code.

4️⃣ Validation : Après saisie du code généré par l’authentificator dans le formule de connexion, le serveur effectue le même calcul. Si les 2 codes correspondent, l’accès aux ressources est autorisée.

authentification totp

Avantages / Inconvénients

Avantages Inconvénients

✅ Application fonctionne hors-ligne, plus sûr que OTP

✅ Basé sur le standard ouvert RFC 6238

✅ Très répandu parmi les services en ligne, il donc facilement déployable.

✅ Plus rapide que l’attente d’un SMS/Mail

✅ Gratuité de la grande majorité des applications TOTP

❌ Toujours vulnérable au phishing : Un attaquant peut demander le code et le réutiliser immédiatement.

❌ Si le secret partagé côté serveur est compromis, tous les TOTP sont compromis.

❌ Comptes inaccessibles si vol du téléphone, application désinstallée par erreur (si les clés de secours n’ont pas été sauvegardées)

❌ Risque de compromission des OTP si :

  • malwares dans l’appareil
  • vol de l’appareil déverrouillé

Quand utiliser ou éviter le TOTP ?

Utiliser Éviter

✅ Sécuriser ses comptes en ligne (réseaux sociaux, messageries, banques, etc.).

✅ Services qui ne supportent pas les tokens physiques

❌ Niveau de sécurité maximal recherché

❌ Appareil partagé ou non sécurisé

❌ Pour des comptes ultra sensibles (ex : administrateur de réseaux)

Notifications push

Principe

L’authentification par notification push consiste à envoyer une notification sur le smartphone de l’utilisateur lorsqu’il tente de se connecter à un service.
L’utilisateur valide ou rejette la tentative en un seul geste (tap), ce qui confirme qu’il possède bien l’appareil enregistré.

Fonctionnement

1️⃣ L’utilisateur entre ses identifiants (nom d’utilisateur + mot de passe) ou une authentification SSO

2️⃣ Le serveur d’authentification envoie une requête chiffrée au service de notification (Apple Push Notification Service ou Google Firebase Cloud Messaging)

3️⃣ Le service de notification transfère le message à l’application d’authentification installée sur l’appareil pour l’afficher à l’écran. 

La demande contient des informations contextuelles :

  • localisation approximative
  • heure
  • application ou service
  • adresse IP
  • parfois un code de correspondance (numéro à valider)

4️⃣ L’utilisateur approuve ou refuse par :

  • bouton “Accepter / Refuser”
  • saisie d’un numéro affiché sur l’écran de login (Number Matching)
  • reconnaissance biométrique (face/fingerprint) faite en local
  • saisie du code PIN de l’application

5️⃣ Le signal d’approbation est envoyé au serveur d’authentification via un canal sécurisé. Le serveur valide l’approbation et accorde l’accès.

Cette méthode est sensible à la fatigue MFA : avec l’inondation de notifications sur son smartphone, un utilisateur pourrait approuver instinctivement la notification alors qu’il n’est pas l’auteur de la demande d’autorisation.

Avantages / Inconvénients

Avantages Inconvénients

✅ Meilleure Expérience Utilisateur (UX)

  • pas de saisie manuelle de code
  • une seule action pour valider

✅ Plus sécurisé que le SMS et l’OTP

  • non interceptable par SIM swapping
  • pas sensible au phishing classique
  • capacité à intégrer de la biométrie

✅ Détection de tentatives frauduleuses

  • L’utilisateur peut refuser une demande grâce aux informations de la notification
  • Un refus d’approbation peut engager une action des sécurités du service (blocage de la connexion, verrouillage du compte…)

✅ Variantes diverses

  • number matching 
  • géolocalisation approximative

❌ Fatigue MFA (Push bombing)

En raison d’une inondations de notifications,

  • l’utilisateur finit par accepter par fatigue
  • ou par erreur
  • ou par réflexe (habitude)

❌ Nécessite un appareil fonctionnel

  • allumé
  • connecté à un réseau (4G/5G ou Wi-Fi)
  • batterie vide

❌ Le push n’est pas un standard (contrairement à FIDO2/WebAuthn ou TOTP)

  • chaque fournisseur a sa propre API
  • aucune interopérabilité native

❌ Possibilité de contournement si l’appareil est compromis

  • malware sur le téléphone
  • jailbreak/root
  • smartphone volé et déverrouillé

Quand utiliser ou éviter la Notification Push ?

Utiliser Éviter

✅ Pour les utilisateurs non techniques

✅ Sécurité meilleure que le SMS ou le mail

✅ Avoir une expérience utilisateur fluide

❌ Si problème de couverture réseau

❌ Appareils non sécurisés

❌ Pour les comptes ultra sensibles

Biométrie

Principes

L’authentification biométrique utilise une caractéristique physique ou comportementale de l’utilisateur :

  • Empreinte digitale (Touch ID, Windows Hello)
  • Reconnaissance faciale (Face ID, Windows Hello)
  • Iris
  • Voix

Elle peut servir de facteur pour l’authentification multifacteurs mais peut être déployée dans un système d’authentification sans mot de passe.

Fonctionnement

  1. Enregistrement : L’utilisateur soumet sa donnée (ex. : scan d’empreinte). Le système crée un gabarit (template), une représentation mathématique chiffrée de la donnée.
  2. Tentative d’Accès : L’utilisateur active le capteur (ex. : pose son doigt).
  3. Capture et Conversion : Le capteur capture la donnée et la convertit en un nouveau gabarit chiffré.
  4. Comparaison : Le système compare le nouveau gabarit avec celui stocké.
  5. Correspondance : Si la correspondance atteint un seuil de confiance prédéfini, l’accès est accordé.
authentification par empreinte digitale

Avantages / Inconvénients

Avantages Inconvénients

✅ Praticité : pas de mot de passe à retenir

✅ Intégrité : difficile à falsifier

✅ Rapidité du processus d’authentification

❌ Coût élevé pour des systèmes d’envergure

❌ Une donnée biométrique compromise ne peut être changée comme un mot de passe

❌ Faux positif : Risque d’erreur du capteur se faisant berner 

❌ Problème de confidentialité : stockage de données biométriques (même si chiffrées)

Quand utiliser ou éviter la biométrie ?

Utiliser Éviter

✅ Authentifications rapides

✅ Éviter les mots de passe et codes

✅ Pour les appareils sécurisés

❌ Appareil non sécurisé ou partagé

❌ Pour les comptes ultra-sensibles (la biométrie peut être contournée)

❌ Crainte sur la confidentialité des données biométriques

Tokens physiques

Principes

Un token physique est un dispositif matériel qui génère un code (OTP) ou chiffre/déchiffre des données d’authentification. Il prouve la possession d’un secret ou d’une clé privée sans la dévoiler.

Il existe deux grandes catégories :

  • tokens classiques : clés USB traditionelles, cartes à puces ou tokens générant des OTP (ex : RSA SecurID).
  • tokens FIDO2 : céls modernes compatibles avec les standards WebAuthn et CTAP (ex : Yubikey)

Les tokens physiques sont utilisés principalement dans le monde de l’entreprise.

Fonctionnement

Tokens non-FIDO2 (ex. : RSA SecurID, OTP hardware)

1️⃣ Initialisation :

  • Le token est configuré lors de l’activation du MFA.
  • Pour les tokens OTP, un secret partagé dans le token et utilisé pour générer des codes à usage unique.

2️⃣ Authentification :

  • L’utilisateur entre son identifiant et son mot de passe.
  • Le système demande un code ou une validation via le token.
    • Pour un token OTP : L’utilisateur lit le code affiché sur l’écran du token et le saisit.
    • Pour un token USB : L’utilisateur branche le token, qui génère ou transmet automatiquement un code ou une signature cryptographique.

3️⃣ Validation :

  • Le serveur vérifie la validité du code ou de la signature.
  • Si le code est correct, l’accès est accordé.

Tokens FIDO2

Les tokens FIDO2 utilisent des protocoles modernes comme WebAuthn et CTAP pour une authentification sans mot de passe ou en double facteur.

1️⃣ Enregistrement du token :

  • L’utilisateur enregistre son token FIDO2 sur un service compatible (ex. : Google).
  • Le token génère une paire de clés cryptographiques (). La clé publique est stockée sur le serveur, la clé privée reste dans le token.

2️⃣ Authentification :

  • L’utilisateur entre son identifiant sur le service.
  • Le service demande une authentification via le token FIDO2.
  • L’utilisateur branche le token (USB) ou l’approche (NFC/Bluetooth).
  • Le service envoie un challenge au dispositif FIDO2.
  • Le token signe cryptographiquement le résultat du challenge avec sa clé privée. Seul la réponse sort du token physique.
  • Le serveur vérifie la signature avec la clé publique enregistrée.

3️⃣ Validation :

  • Si la signature est valide, l’accès est accordé.
Authentification avec token FIDO2
Avantages Inconvénients

✅ Sécurité maximale

  • Impossible à pirater à distance : pas de code interceptable
  • Totalement résistant au phishing et aux attaques par malware ou de type MitM
  • Pas de secret partagé

✅ Durabilité : Les tokens FIDO2 peuvent durer des années

✅ Simplicité d’utiilsation

  • Authentification biométrique
  • Pas besoin de taper un code
  • Très rapide
  • Peut servir à la fois de second facteur et de solution passwordless selon la configuration
  •  

❌ Si perte du dispositif, perte d’accès aux comptes sans les clés de secours

❌ Nécessite un système compatible

❌ Coût : Achat entre 20 et 100 € l’unité.

❌ Toujours être en possession du token sur soi

Quand utiliser ou éviter le TOTP ?

Utiliser Éviter

✅ Sécuriser des comptes ultra-sensibles (administrateurs système, comptes bancaires, accès root)

✅ Avoir une solution sans mot de passe

✅ Être une cible potentielle de cyberattaque

❌ Petit budget

❌ Services utilisés non compatibles

❌ Perte potentielle du dispositif (ex : tête en l’air, déplacements réguliers)

Tokens numériques (jetons)

Principes

Un token numérique d’authentification (ou jeton d’accès) est une chaîne de caractères chiffrée qui représente l’identité d’un utilisateur après que celui-ci ait réussi la phase d’authentification initiale (nom d’utilisateur et mot de passe).

Au lieu d’utiliser les identifiants de l’utilisateur pour chaque requête adressée à un serveur ou à une application (méthode dite « basée sur session » ou « basée sur cookie » classique), l’utilisateur présente ce token. Le token est donc une preuve d’identité temporaire et sécurisée.

Le type de token le plus courant dans le développement web moderne est le JSON Web Token (JWT), qui est un standard ouvert (RFC 7519).

Caractéristiques

Les tokens numériques possèdent plusieurs caractéristiques qui les distinguent des méthodes d’authentification traditionnelles :

  • Autonome (Stateless) : Le token contient toutes les informations nécessaires (identité de l’utilisateur, permissions, expiration). Le serveur n’a pas besoin de stocker une « session » côté serveur pour vérifier l’identité. Il lui suffit de vérifier la signature du token.
  • Sécurisé par Cryptographie : Les tokens sont généralement signés numériquement à l’aide d’un algorithme (comme HMAC-SHA256). Cette signature garantit deux choses :
    • Intégrité : Le contenu du token n’a pas été modifié pendant le transit.
    • Authenticité : Le token a bien été émis par le serveur (qui est le seul à détenir la clé secrète).
  • Composants (pour un JWT) : Un JWT est généralement composé de trois parties, séparées par des points (.):
    • En-tête (Header) : Contient le type de token (JWT) et l’algorithme de signature utilisé.
    • Charge utile : Informations (claims) sur l’utilisateur et le token lui-même (ex: l’identifiant de l’utilisateur, la date d’émission, la date d’expiration).
    • Signature : Créée en encodant l’En-tête, la Charge utile, et un secret connu uniquement du serveur.
  • Durée de vie limitée : Ils ont une date d’expiration (exp claim) intégrée pour minimiser le risque de compromission.

Fonctionnement

Le cycle de vie de l’authentification par token se décompose en trois phases principales : l’enregistrement/connexion, l’émission du token, et l’utilisation/validation.

1️⃣ Enregistrement / Connexion (Phase d’Authentification Initiale)

  • Requête de connexion : L’utilisateur envoie ses identifiants (nom d’utilisateur/e-mail et mot de passe) au serveur d’authentification.
  • Vérification : Le serveur vérifie que les identifiants correspondent aux informations stockées (généralement dans une base de données).

2️⃣ Émission et Stockage du Token

  • Génération du Token : Si les identifiants sont valides, le serveur crée un nouveau token numérique (par exemple, un JWT). Il encode les informations de l’utilisateur dans la Charge utile et le signe avec sa clé secrète.
  • Envoi du token : Le serveur renvoie ce token généré au client (navigateur ou application mobile).
  • Stockage Côté Client : Le client stocke le token, souvent dans le stockage local (localStorage) du navigateur ou dans un cookie HTTP Only (l’option préférée pour des raisons de sécurité contre les attaques XSS).

3️⃣ Validation de Connexion (Accès aux Ressources)

  • Requête d’Accès : Pour accéder à une ressource protégée (ex: charger un profil utilisateur, envoyer un commentaire), le client ajoute le token à l’en-tête de la requête HTTP (généralement dans l’en-tête Authorization: Bearer <token>).
  • Vérification du Token (Côté Serveur) :
    • Le serveur reçoit la requête.
    • Il vérifie la signature du token à l’aide de sa clé secrète pour s’assurer qu’il n’a pas été altéré et qu’il a bien été émis par lui.
    • Il vérifie la date d’expiration.
  • Autorisation et Réponse : Si le token est valide et non expiré, le serveur décode la Charge utile pour identifier l’utilisateur et ses permissions, puis accorde l’accès à la ressource. Le serveur renvoie la réponse au client.
Schéma token numérique

Avantages / Inconvénients

Avantages Inconvénients

✅ Sécurité renforcée : Le secret (mot de passe) n’est transmis qu’une seule fois. La signature cryptographique protège l’intégrité du token.

✅ Stateless (sans état) : Le serveur n’a pas besoin de faire de recherche en base de données pour vérifier la session, ce qui réduit la charge et améliore les performances.

✅ Évolutivité (Scalabilité) : Facilite la répartition de charge de travail entre plusieurs serveurs puisque le token est auto-validant et ne nécessite pas de recherche dans la base de données de ssessions.

✅ Séparation entre application et authentification : Grâce au token autonome, l’architecture peut être divisée en deux :

  • service Authentification (Identity Provider (IdP)
  • service d’application (Ressource Server)

❌ Stockage client du jeton piratable : Si un token est volé, il reste valide jusqu’à son expiration, il donne un accès immédiat au service.

  • localStorage : vulnérable au XSS
  • cookies : vulnérables au CSRF si mal configurés
  • applications mobiles : exfiltration

❌ Taille : Les tokens (surtout les JWT) sont plus volumineux que les cookies de session simples, car ils contiennent les données utilisateur (payload) et doivent être envoyés avec chaque requête.

❌Complexité de révocation : La révocation immédiate d’un token compromis ou après une déconnexion est plus complexe (nécessite une « liste noire » ou des mécanismes supplémentaires).

❌ Sensibilité : La Charge utile d’un token peuvent être lues par le client (est encodée, non chiffrée, seulement signée).  Ne pas y mettre de données sensibles !

Quand utiliser / éviter le token numérique

Utiliser Éviter

✅ Applications Web et mobiles modernes

✅ Idéal sur les API pour communiquer entre services

✅ Permet à une application un accès délégué (OAuth 2.0) sur des ressources sans partager les identifiants de l’utilisateur

❌ Systèmes critiques avec niveau de sécurité élevés : le token peut être volé

❌ Environnement en HTTP : vulnérabilité aux interceptions

❌ Applications nécessitant une révocation immédiate

6. Authentification par Single Sign-On (SSO)

Le Single Sign-On (SSO) est un mécanisme d’authentification qui permet à un utilisateur de  de se connecter une seule fois pour accéder à plusieurs services.

Fonctionnement

Le SSO est un concept est non une technique. Je vais vous présenter 2 possibilités :

SAML Token (JWT)
Utilisé principalement en entreprise
Utilisé par les applications modernes, API (Exemple : « Se connecter avec Google » sur un site Web)

3 acteurs  :

  • L’utilisateur : La personne qui souhaite accéder à une application
  • Le fournisseur d’identité (IdP – Identity Provider) : Système qui authentifie l’utilisateur
  • Le fournisseur de service (SP – Service Provider) : Application ou service que l’utilisateur veut utiliser.

4 acteurs  :

  • Utilisateur → La personne qui veut accéder à l’application.
  • Client (Application) → L’application ou le service (ex. : kChat, une SPA, une API).
  • Fournisseur d’identité (IdP) → Le serveur d’autorisation qui authentifie l’utilisateur et émet les tokens (ex. : Google, Okta).
  • Serveur de ressources (Resource Server) → L’API ou le service qui protège les données (parfois intégré au client).

1️⃣ L’utilisateur tente de se connecter à une application (SP)

  • Le SP détecte que l’utilisateur n’est pas authentifié.
  • Il redirige l’utilisateur vers l’IdP (avec une requête d’authentification SAML)

1️⃣L’utilisateur tente d’accéder à l’application (Client)
Exemple : L’utilisateur clique sur “Se connecter avec Google” dans kChat.

  • Le Client détecte que l’utilisateur n’est pas authentifié.
  • Le client (kChat) redirige l’utilisateur vers l’endpoint d’autorisation de l’IdP avec une requête OAuth 2.0

2️⃣ L’IdP vérifie si l’utilisateur est déjà authentifié

  • Si oui (session active) : l’IdP génère un assertion SAML (ticket crypté contenant les infos de l’utilisateur) et le renvoie au SP
  • Si non, l’IdP affiche un formulaire de connexion (login/mot de passe, MFA, etc…)

2️⃣ L’IdP vérifie si l’utilisateur est déjà authentifié

  • Si l’utilisateur est déjà connecté : l’IdP sautera cette étape
  • Si l’utilisateur n’est pas déjà connecté : l’IdP affiche un formulaire de connexion (email/mot de passe, MFA, etc.).

 

3️⃣ L’utilisateur s’authentifie auprès de l’IdP

  • L’utilisateur entre ses identifiants.
  • L’IdP valide les credentials via base de données (ou annuaire LDAP)
  • Si l’authentification réussit, l’IdP géère un assertion SAML signé.

3️⃣ L’utilisateur s’authentifie auprès de l’IdP

L’IdP redirige l’utilisateur vers le client avec un code d’autorisation
→ L’IdP génère un code d’autorisation temporaire et le renvoie au client via le redirect_uri :

https://kchat.infomaniak.com/callback?code=AUTH_CODE&state=STATE
→ Le code est valide quelques minutes et ne peut être utilisé qu’une seule fois.

4️⃣ L’IdP redirige l’utilisateur vers le SP avec l’assertion SAML

Le navigateur de l’utilisateur est redirigé vers le SP avec un formulaire POST contenant l’assertion SAML.

4️⃣  Le client échange le code contre des tokens

  • Le client envoie une requête POST au token endpoint de l’IdP
  • L’IdP valide le code, le client_secret, et le redirect_uri puis renvoie une réponse au client

5️⃣ Le SP valide l’assertion SAML

Le SP vérifie :

  • La signature de l’assertion (avec la clé publique de l’IdP).
  • L’assertion n’est pas expirée.
  • L’assertion est destinée à ce SP (Audience).

Si tout est valide, le SP crée une session locale pour l’utilisateur. L’utilisateur est connecté.

5️⃣ Le Client valide le ID Token (JWT)

Le client vérifié :

  • La signature du JWT (avec la clé publique de l’IdP).
  • Qu’il s’agit de son client.
  • Le token n’est pas dépassé.
  • La correspondance avec sa requête OAuth à l’étape 1.

Si tout est valide, l’utilisateur est authentifié.

6️⃣ L’utilisateur accède à l’application

  • L’utilisateur peut maintenant utiliser l’application sans avoir à se reconnecter.
  • Si l’utilisateur accède à un autre SP (ex. : kChat), le même processus se répète, mais sans redemande de mot de passe car l’IdP a déjà authentifié l’utilisateur.

6️⃣ Le client utilise l’Access Token pour accéder aux ressources

  • Le client envoie l’Access Token dans l’en-tête HTTP pour accéder à l’API (ex. : kDrive, kMeet)
  • Le serveur de ressources (ex. : API de kDrive) :
    • Valide le token (signature, expiration, audience).
    • Extrait les scopes ou rôles pour autoriser l’accès.

7️⃣ L’utilisateur est connecté et peut utiliser l’application

  • Le client stocke les tokens (sécurément) et crée une session locale. 
  • L’utilisateur peut accéder à d’autres services (ex. : kMeet, kChat) sans se reconnecter car l’IdP a déjà authentifié l’utilisateur.

Le SSO avec un token JWT est un hybride entre :

  • le concept SSO
  • la méthode token numérique

Avantages / Inconvénients

Avantages Inconvénients

✅ Expérience utilisateur simplifiée

  • Un seul identifiant/mot de passe pour accéder à plusieurs services, moins fatigue de l’utilisateur.
  • Moins de interruptions liées aux connexions répétées.

✅ Sécurité renforcée

  • Surface d’attaque liée aux mots de passe diminuée (moins de mots de passe faibles et réutilisés)
  • Traçabilité facilitée des connexions
  • Compatible avec des solutions d’IAM (Identity and Access Management)

✅ Conformité et intégrabilité

  • Meilleur contrôle d’accès et auditabilité (RGPD, ISO 27001)
  • Facilité d’intégration d’applications tierces (SMAL, OAuth 2.0)
  •  

❌ Point de défaillance unique

  • Si l’IdP indisponible,  connexion aux services impossible.
  • Si l’IdP est compromis, l’attaquant a accès à toutes les applications connectées.

❌ Complexité d’implémentation

Nécessite une configuration technique (protocoles, certificats, fédérations). Cela nécessite un coût et du temps.

❌ Surcentralisation

Trop de privilèges concentrés sur un seul compte. Risque élevé en cas de compromission.

❌ Dépendance au fournisseur SSO

En cas de panne ou mise à jour du système SSO, blocage des accès.

Comparatif

Critère OTP SMS/Mail TOTP Push Token FIDO2 Token numérique Biométrie SSO
Sécurité
🟧
🟨🟨
🟨🟨
🟩🟩🟩
🟩🟩🟩
🟩🟩🟩
🟨🟨
Expérience utilisateur
🟧
🟨🟨
🟩🟩🟩
🟨🟨
transparent pour l’utilisateur
🟩🟩🟩
🟩🟩🟩
Dépendance réseau
Oui
Non
Oui
Non
Oui (nécessite un serveur)
Non (souvent locale)
Oui (nécessite IdP)
Risque de perte
🟩🟩🟩
🟨🟨
🟨🟨
🟧
🟧
🟩🟩🟩
🟩🟩🟩 Faible
Standard de sécurité
❌
✔️ (RFC 6238 )
❌ Non mais bonne pratique
✔️ Oui (FIDO2 / WebAuthn)
✔️ Oui (RFC 7519)
❌ Non (mais règlementé)
✔️ Oui (mais dépend des protocoles)

Sécurité vs. Confort :

C’est l’éternel débat entre efficacité sécuritaire et opérationnelle. Plus on renforce l’une, plus on réduit l’autre. Les méthodes comme FIDO2 ou la biométrie offrent une sécurité élevée, mais peuvent être plus complexes à déployer dans une organisation. À l’inverse, l’OTP SMS est simple mais vulnérable.

Pour le grand public, c’est légèrement différent car les utilisateurs ne s’occupent pas du déploiement et de la gestion du système. Ce serait plus un rapport Sécurité / Expérience utilisateur (UX). 

Certains services permettent d’utiliser un facteur de la MFA comme preuve principale et se passer du mot de passe. On appelle ce système passwordless.

Contexte d’utilisation :

  • Pour le grand public, TOTP ou notifications push sont plus adaptés.
  • Pour les entreprises, FIDO2 ou SSO JWT accorde une sécurité renforcée et une gestion centralisée