Les parcours d'authentification et le MFA

Le MFA est rarement un interrupteur unique. Dans une architecture réelle, il varie selon la population, l’application et l’opération demandée, et il faut organiser son activation pour des comptes qui n’ont encore aucun facteur. Keycloak exprime tout cela avec des flux d’authentification composés de briques. Ce cours montre ce que ces briques permettent nativement, où commencent les extensions, et comment construire une offre de MFA par paliers. Les notions de facteur et de niveau d’assurance sont supposées connues (voir les fondations).

Anatomie d’un flux d’authentification

Un flux est une suite d’exécutions (authenticators) et de sous-flux. Chaque élément a une exigence :

• Required : doit réussir ;
• Alternative : au moins un des éléments alternatifs du niveau doit réussir ;
• Disabled : ignoré ;
• Conditional (sous-flux seulement) : exécuté si toutes ses conditions sont vraies.

Les flux sont liés au realm pour chaque usage : navigateur (browser flow), inscription, réinitialisation des credentials, direct grant, authentification des clients, first broker login. Un client peut surcharger les liaisons browser et direct grant (voir le cours 2).

Le flux browser par défaut de Keycloak 26.4 se lit ainsi :

browser
├── Cookie                                   Alternative
├── Kerberos                                 Disabled
├── Identity Provider Redirector             Alternative
├── Organization                             Alternative
│   └── Browser - Conditional Organization   Conditional
└── forms                                    Alternative
    ├── Username Password Form               Required
    └── Browser - Conditional 2FA            Conditional
        ├── Condition - user configured      Required
        ├── Condition - credential           Required
        ├── OTP Form                         Alternative
        ├── WebAuthn Authenticator           Disabled
        └── Recovery Authentication Code Form Disabled

Par défaut, le second facteur n’est donc demandé qu’aux utilisateurs qui en ont configuré un, et pas à ceux qui viennent de se connecter avec une passkey. Le MFA est optionnel tant qu’on ne change rien.

Les sous-flux conditionnels

Les conditions disponibles nativement en 26.4 :

S’y ajoutent deux authenticators utiles dans ces sous-flux : Deny access (avec un message) et Allow access. Exemple de politique « MFA obligatoire pour tous, enrôlement forcé » : après le sous-flux 2FA, un sous-flux conditionnel avec Condition - sub-flow executed (non exécuté) puis OTP Form en Required.

Les required actions

Une required action est une étape que l’usager doit accomplir avant d’accéder à l’application. Keycloak 26.4 fournit notamment : Verify Email, Update Password, Update Profile, Verify Profile, Configure OTP, Webauthn Register, Webauthn Register Passwordless, Recovery Authentication Codes, Update Email, Terms and Conditions, Delete Account, Update User Locale.

Elles se déclenchent de trois façons :

• par l’administrateur, sur un compte ou en masse (après une reprise : Update Password, Configure OTP) ;
• par défaut pour tout nouveau compte (option Default action) ;
• par l’application, avec le paramètre kc_action (Application Initiated Action), par exemple kc_action=CONFIGURE_TOTP depuis une page « Sécuriser mon compte ».

kcadm.sh update users/$USER_ID -r academy -s 'requiredActions=["VERIFY_EMAIL","CONFIGURE_TOTP"]'

Le parcours de migration d’une population vers le MFA se construit avec ces briques : annonce, période où l’enrôlement est proposé (kc_action ou required action), puis bascule où le facteur devient obligatoire (condition sur un rôle ou un attribut posé par lot).

Les facteurs disponibles

Pour une architecture de service public, les recommandations de l’ANSSI sur l’authentification multifacteur sont le référentiel pour classer ces facteurs par robustesse.

MFA différencié : ACR, LoA et step-up

Keycloak raisonne en niveaux d’authentification (LoA, des entiers) et expose aux applications des valeurs ACR (chaînes). On déclare la correspondance dans les réglages généraux du realm (recommandé) ou sur un client :

kcadm.sh update realms/academy -s 'attributes."acr.loa.map"="{\"standard\":1,\"renforce\":2}"'

Le flux browser contient alors un sous-flux conditionnel par niveau, chacun avec Condition - Level of Authentication (niveau, et Max Age : durée pendant laquelle ce niveau reste acquis dans la session). Les niveaux sont ordonnés du plus faible au plus fort, et chaque niveau inclut les facteurs du précédent.

L’application demande un niveau avec acr_values=renforce (non essentiel) ou avec le paramètre claims en marquant acr comme essentiel. Si l’utilisateur a déjà une session de niveau 1, Keycloak ne lui demande que le facteur manquant : c’est le step-up. Le claim acr, ajouté par le client scope acr présent par défaut, indique le niveau atteint. Dans l’exemple ci-dessous, on suppose qu’il reprend la valeur ACR demandée ; sans demande explicite, il contient le numéro du niveau (1, ou 0 si le niveau a expiré et que seule la session SSO a servi) :

{
  "iss": "http://localhost:8080/realms/academy",
  "azp": "portail-sensible",
  "acr": "renforce",
  "auth_time": 1793876110
}

Côté client, trois réglages complètent le dispositif :

Le step-up par conditions de niveau suppose des niveaux emboîtés. Si un niveau exige un facteur différent (et non additionnel), la documentation oriente vers les client policies, qui sélectionnent un flux complet selon l’ACR demandé ou d’autres conditions (depuis 26.2). Le step-up existe aussi pour SAML via un mapping ACR vers URI : en préversion en 26.6, puis annoncé pour les clients SAML en 26.7, à vérifier selon la version déployée.

C’est la base d’une offre de service par paliers : palier 1 mot de passe, palier 2 mot de passe et OTP ou WebAuthn, palier 3 passkey ou clé matérielle seule, chaque application étant rattachée à un palier par son Minimum ACR value.

Mots de passe, force brute et sessions

Politique de mots de passe (par realm) : longueur, classes de caractères, différent du nom d’utilisateur et de l’e-mail, historique, expiration, liste de mots interdits, expression régulière, algorithme et itérations de hachage, âge maximal d’authentification avant changement. Une nouvelle politique ne s’applique pas aux mots de passe existants avant leur prochain changement.

Protection contre la force brute : désactivée par défaut. Elle s’applique au mot de passe, à l’OTP et aux codes de récupération. Deux modes : verrouillage temporaire (attente qui croît avec les échecs, plafonnée) ou permanent (jusqu’à déblocage par un administrateur), ainsi qu’un mode mixte : verrouillage permanent après un nombre donné de verrouillages temporaires. Le message affiché reste « identifiant ou mot de passe invalide » pour ne rien révéler. Depuis 26.8, les compteurs d’échec sont stockés en base par défaut et survivent aux redémarrages.

kcadm.sh update realms/academy -s bruteForceProtected=true -s permanentLockout=false \
  -s failureFactor=5 -s waitIncrementSeconds=60 -s maxFailureWaitSeconds=900

Sessions : SSO Session Idle (30 minutes par défaut) et SSO Session Max (10 heures) au niveau du realm, Remember me avec ses propres durées, sessions hors ligne pour les refresh tokens longs. Un client peut raccourcir ses propres durées sans dépasser celles du realm.

Le MFA adaptatif : ce qui manque

Keycloak n’a pas de moteur de risque. Il ne calcule pas de score à partir de l’adresse IP, de l’appareil, de la géolocalisation ou du comportement. Ce qu’il offre nativement :

• des conditions statiques (rôle, attribut, client, facteur utilisé, niveau) ;
• l’authenticator historique Conditional OTP Form, encore présent en 26.4, qui peut forcer ou sauter l’OTP selon un rôle ou un en-tête HTTP posé par un équipement amont ;
• les événements de connexion, exploitables a posteriori par un SIEM (cours 9).

Un MFA adaptatif demande donc une extension : une condition ou un authenticator qui évalue un contexte (plage d’adresses, cookie d’appareil connu, heure, pays) ou qui interroge un moteur de risque externe, puis déclenche un sous-flux renforcé. Il faut aussi stocker l’historique des appareils et prévoir l’explicabilité des refus pour le support. Présentez-le comme un chantier à part entière, pas comme une option à cocher.

kcadm() { docker compose exec -T keycloak /opt/keycloak/bin/kcadm.sh "$@"; }
kcadm config credentials --server http://localhost:8080 --realm master --user admin --password admin
kcadm create realms -s realm=academy -s enabled=true
kcadm create roles -r academy -s name=mfa-requis
for U in agent-mfa agent-simple; do
  kcadm create users -r academy -s username=$U -s email=$U@example.org \
    -s firstName=Agent -s lastName=$U -s enabled=true -s emailVerified=true
  kcadm set-password -r academy --username $U --new-password 'Academy2026!'
done
kcadm add-roles -r academy --uusername agent-mfa --rolename mfa-requis

kcadm create authentication/flows/browser/copy -r academy -s newName=navigateur-mfa
kcadm get authentication/flows/navigateur-mfa/executions -r academy --fields displayName,requirement,level

kcadm update realms/academy -s browserFlow=navigateur-mfa

kcadm remove-roles -r academy --uusername agent-mfa --rolename mfa-requis

kcadm update realms/academy -s bruteForceProtected=true -s failureFactor=3

ID=$(kcadm get users -r academy -q username=agent-simple --fields id --format csv --noquotes)
kcadm get attack-detection/brute-force/users/$ID -r academy
kcadm delete attack-detection/brute-force/users/$ID -r academy