Skip to Content

Authentification Multi-Facteur (MFA)

L’authentification multi-facteur exige des utilisateurs qu’ils fournissent une deuxième forme de vérification au-delà des credentials primaires. Auris supporte quatre mécanismes MFA — applications authenticator TOTP, mots de passe à usage unique via SMS, clés hardware et passkeys WebAuthn, et MFA adaptative basée sur le risque qui active automatiquement des facteurs supplémentaires selon le risque détecté — qui peuvent être combinés selon ta politique de sécurité.

TOTP (App Authenticator)

Le Time-Based One-Time Password (TOTP) est le mécanisme MFA le plus largement supporté. Les utilisateurs scannent un QR code avec une application authenticator — comme Google Authenticator, Authy, 1Password, ou toute application conforme RFC 6238 — et saisissent le code à six chiffres qu’elle génère.

Comment ça Fonctionne

Les codes TOTP sont dérivés d’un secret partagé et de l’heure courante. Le serveur et l’app authenticator calculent indépendamment le même code pour chaque fenêtre de 30 secondes. Aucune connexion réseau n’est requise sur l’appareil de l’utilisateur.

Configuration Utilisateur

Le flux d’enrôlement TOTP :

  1. L’utilisateur navigue vers Compte → Sécurité → Authentification à Deux Facteurs.
  2. Un QR code et une clé de saisie manuelle sont affichés.
  3. L’utilisateur scanne le QR code avec son application authenticator.
  4. L’utilisateur saisit le code initial à six chiffres pour confirmer la configuration.
  5. Les codes de récupération sont générés et présentés à l’utilisateur. L’utilisateur doit les sauvegarder — ils ne peuvent pas être récupérés ultérieurement.

Codes de Récupération

Chaque configuration TOTP génère 10 codes de récupération à usage unique. Si un utilisateur perd l’accès à son appareil authenticator, il peut saisir un code de récupération pour contourner la MFA et se connecter. Après utilisation, un code de récupération est invalidé. Les utilisateurs peuvent générer un nouveau jeu de codes de récupération depuis leur page de sécurité du compte — cela invalide tous les codes précédents.

Actions Administratives

Les administrateurs peuvent réinitialiser l’enrôlement TOTP d’un utilisateur via la Console (Détail utilisateur → Sécurité → Réinitialiser TOTP). Cela supprime la configuration TOTP existante et force l’utilisateur à se ré-enrôler à la prochaine connexion. Utilise cela quand un utilisateur signale un appareil perdu ou remplacé.

POST/api/user/2fa/totp/enable

Initie l’enrôlement TOTP pour l’utilisateur authentifié. Retourne le secret TOTP et l’URI de données du QR code.

POST/api/user/2fa/totp/verify

Confirme l’enrôlement en vérifiant le code TOTP initial. Génère et retourne les codes de récupération.

DELETE/api/user/2fa/totp

Supprime l’enrôlement TOTP de l’utilisateur. Nécessite le code TOTP courant ou un code de récupération pour confirmation.

SMS OTP

Les mots de passe à usage unique via SMS délivrent un code de vérification au numéro de mobile enregistré de l’utilisateur par SMS. Auris utilise Twilio comme fournisseur SMS.

Prérequis

SMS OTP nécessite :

  • Un compte Twilio avec un numéro de téléphone capable d’envoyer des SMS.
  • Les variables d’environnement TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN et TWILIO_FROM_NUMBER configurées dans l’API Auris.

Pour un guide complet de configuration de SMS OTP incluant la configuration Twilio, voir Authentification SMS OTP.

Configuration Utilisateur

  1. L’utilisateur navigue vers Compte → Sécurité → Numéro de Téléphone.
  2. L’utilisateur saisit son numéro de mobile au format E.164 (ex. +33 6 12 34 56 78).
  3. Auris envoie un code de vérification par SMS.
  4. L’utilisateur saisit le code pour confirmer la propriété du téléphone.
  5. Le numéro de téléphone est vérifié et peut être utilisé pour la MFA SMS OTP.

Limitation de Débit

Pour prévenir les abus, Auris applique des limites de débit aux codes SMS OTP :

  • Maximum 5 codes envoyés par numéro de téléphone par heure.
  • Un délai de 30 secondes entre les demandes d’envoi.
  • Maximum 5 tentatives de vérification par code avant qu’il soit invalidé.
POST/api/user/phone

Définit le numéro de téléphone de l’utilisateur et envoie un code de vérification.

POST/api/user/phone/verify

Vérifie le numéro de téléphone avec le code reçu par SMS.

POST/api/user/2fa/sms/enable

Active SMS OTP comme second facteur après que le numéro de téléphone est vérifié.

POST/api/user/2fa/sms/send

Envoie un nouveau code SMS OTP pendant un défi MFA.

WebAuthn / Passkey

WebAuthn (Web Authentication, FIDO2) permet aux utilisateurs de s’authentifier en utilisant des clés hardware de sécurité (YubiKey, Titan Key) ou des authentificateurs de plateforme (Touch ID, Face ID, Windows Hello). Utilisé comme second facteur, l’utilisateur touche sa clé hardware ou utilise la biométrie pour compléter le défi MFA.

Les credentials WebAuthn sont résistants au phishing par conception : le credential est lié à l’origin spécifique (domaine) et ne peut pas être reproduit sur un site différent.

Pour un guide complet de configuration WebAuthn, voir WebAuthn / Passkey.

Configuration Utilisateur

  1. L’utilisateur navigue vers Compte → Sécurité → Passkeys.
  2. L’utilisateur clique “Enregistrer une Passkey” et fournit un nom pour le credential.
  3. Le navigateur présente une demande d’authentification de plateforme (Touch ID, Windows Hello, ou une clé hardware).
  4. Le credential est enregistré. L’utilisateur peut enregistrer plusieurs passkeys pour différents appareils.

Pendant le Défi MFA

Quand la MFA WebAuthn est requise, la page Hosted Login présente un défi WebAuthn. L’authentificateur enregistré de l’utilisateur gère la réponse cryptographique — aucun code à saisir.

POST/api/user/2fa/webauthn/enable

Initie l’enregistrement WebAuthn comme second facteur. Retourne le défi d’enregistrement.

POST/api/user/2fa/webauthn/challenge

Génère un défi d’authentification pour une vérification MFA en cours.

DELETE/api/user/2fa/webauthn

Supprime un credential WebAuthn enregistré par ID de credential.

MFA Adaptative (Basée sur le Risque)

La MFA adaptative évalue un score de risque à chaque connexion et intensifie automatiquement l’exigence d’authentification quand le risque est élevé. Au lieu de toujours ou jamais exiger la MFA, Auris répond de façon proportionnelle au risque effectif de chaque tentative de connexion.

Facteurs de Risque

Auris calcule un score de risque à partir de cinq facteurs pondérés :

FacteurDescriptionDéclencheur d’exemple
Réputation IPAdresse IP associée à une activité malveillante connue, VPN, proxy ou datacenterConnexion depuis un nœud de sortie Tor
Confiance appareilEmpreinte d’appareil inconnue (aucune connexion réussie précédente depuis cet appareil)Première connexion depuis un nouvel ordinateur portable
Anomalie géographiqueVoyages impossibles — la distance entre la position de connexion précédente et actuelle implique un déplacement plus rapide que possibleConnexion de France suivie 30 minutes plus tard d’une connexion du Japon
Patterns comportementauxHeure de connexion, cadence des requêtes et autres signaux comportementaux qui s’écartent de la baseline de l’utilisateurConnexion à 3h du matin quand l’utilisateur accède toujours pendant les heures de travail
Sensibilité de l’actionLes opérations plus sensibles (ex. changement d’e-mail, génération de clés API) sont évaluées plus rigoureusementUtilisateur tentant de changer son mot de passe immédiatement après la connexion

Les facteurs sont combinés en un score de risque final de 0 à 100.

Seuils de Risque

Configure les seuils dans Console → Sécurité → MFA Adaptative :

SeuilComportement
Faible (0–30)Aucune authentification supplémentaire requise. La connexion standard procède.
Moyen (31–70)Exiger n’importe quelle méthode MFA configurée (TOTP, SMS ou WebAuthn).
Élevé (71–100)Exiger une méthode MFA plus robuste. Le seul TOTP ne suffit pas — WebAuthn hardware est préféré.

Ces seuils sont configurables. Tu peux aussi désactiver complètement la MFA adaptative et utiliser une politique fixe.

ACR et AMR dans les Tokens

Quand une authentification step-up se produit, Auris inclut des claims standard dans l’access token :

  • ACR (Authentication Context Class Reference) : Le niveau de garantie atteint. Par exemple, urn:mace:incommon:iap:silver pour les sessions vérifiées avec MFA.
  • AMR (Authentication Methods References) : Les méthodes d’authentification utilisées. Par exemple, ["pwd", "totp"] pour mot de passe + TOTP, ou ["pwd", "hwk"] pour mot de passe + clé hardware.

Le serveur de ton application peut inspecter ces claims pour appliquer le contrôle d’accès au niveau session.

Authentification Step-Up

L’authentification step-up permet à ton application d’exiger une vérification supplémentaire pour des opérations spécifiques dans une session existante, sans forcer une reconnexion complète.

Par exemple, un utilisateur est connecté et navigue vers “Supprimer le Compte”. Ton application peut déclencher un défi step-up exigeant que l’utilisateur se ré-authentifie (saisir le mot de passe) ou complète un facteur MFA avant que l’action destructive procède.

Auris implémente le step-up via ACR dans la requête d’autorisation. Quand ton application demande un code d’autorisation avec acr_values=2fa, Auris vérifie le niveau ACR de la session courante et demande une authentification supplémentaire seulement si la session ne satisfait pas déjà l’exigence.

L’authentification step-up s’appuie sur les claims AMR de la session. Une session authentifiée avec TOTP (amr: ["pwd", "totp"]) ne sera pas redemandée pour TOTP pendant la validité de la même session, sauf si l’exigence ACR spécifie une méthode pas encore présente.

Configuration dans la Console

Les paramètres MFA sont disponibles dans Console → Authentification → Paramètres MFA.

Toggle par méthode :

MéthodeToggleNotes
TOTPActiver/DésactiverActiver pour permettre aux utilisateurs d’enrôler des apps authenticator
SMS OTPActiver/DésactiverNécessite Twilio configuré dans les variables d’environnement
WebAuthnActiver/DésactiverNécessite HTTPS (les passkeys ne fonctionnent pas sur HTTP simple)
MFA AdaptativeActiver/DésactiverQuand désactivée, la politique statique s’applique à tous les utilisateurs

Politique d’application :

PolitiqueSignification
optionalLes utilisateurs peuvent configurer la MFA mais n’y sont pas obligés
requiredTous les utilisateurs doivent enrôler au moins une méthode MFA pour compléter la connexion
adaptiveLa MFA n’est requise que quand le score de risque dépasse le seuil configuré

Seuils de risque : Curseurs configurables pour les limites Faible/Moyen/Élevé et les poids par facteur.

Permissions Requises

Tous les endpoints de gestion MFA opèrent sur le compte de l’utilisateur authentifié et ne nécessitent pas de permissions spéciales au-delà de l’authentification. Les opérations au niveau admin (réinitialisation du TOTP d’un autre utilisateur, visualisation de l’état MFA) nécessitent manage:users.

Pages Associées

Architecture