Flux d’authentification Keycloak¶

Pourquoi les flux sont-ils configurables ?¶

Un authentication flow est un parcours composé d’exécutions : formulaire, vérification d’identifiant, OTP, condition, redirection vers un fournisseur d’identité, etc. Keycloak utilise des flux distincts selon le contexte (navigateur, inscription, authentification directe, liaison d’identité ou première connexion via broker). Ils déterminent comment vérifier l’utilisateur, pas les permissions métier.

Les exécutions ont notamment des exigences comme REQUIRED (doit réussir), ALTERNATIVE (une possibilité parmi plusieurs branches) ou DISABLED (non exécutée). Certaines versions proposent aussi des exigences conditionnelles ou des sous-flux. La disponibilité et les libellés peuvent différer d’une version à l’autre.

Parcours navigateur représentatif¶

Le flux intégré de Keycloak comporte plusieurs branches et configurations. Le diagramme ci-dessous est schématique, non une copie exhaustive d’un flux par défaut : configurez chaque exécution selon le niveau de risque et la version utilisée.

flowchart TD
    Start[Début : demande d'authentification] --> Cookie{Session SSO valide ?}
    Cookie -->|Oui| Existing[Réutiliser la session]
    Cookie -->|Non| Username[Formulaire identifiant / mot de passe]
    Username --> Password{Identifiants valides ?}
    Password -->|Non| Error[Erreur ou nouvelle tentative]
    Password -->|Oui| Policy{MFA requis ?}
    Policy -->|Non| Success[Authentification réussie]
    Policy -->|Oui| HasOTP{OTP configuré ?}
    HasOTP -->|Oui| OTP[Saisir le code TOTP]
    HasOTP -->|Non| Enroll[Action requise : configurer OTP]
    Enroll --> OTP
    OTP --> OTPValid{Code valide ?}
    OTPValid -->|Non| Error
    OTPValid -->|Oui| Success
    Success --> Return[Retour OIDC / SAML vers le client]
    Existing --> Return

Required actions, TOTP et WebAuthn¶

Une required action est une tâche obligatoire à effectuer par l’utilisateur, par exemple mettre à jour son mot de passe, confirmer son profil, vérifier son email ou configurer une méthode MFA. Elle peut être imposée par l’administrateur ou par un flux. Les actions disponibles dépendent de la version et des extensions installées.

• TOTP : application d’authentification génère un code à usage court à partir d’un secret partagé et de l’heure. Dans la console, activer le fournisseur OTP et les politiques (algorithme, période, chiffres, tolérance), puis ajouter l’action de configuration ou intégrer l’étape dans un flux adapté. Fournir des codes de récupération selon la politique. Le secret QR doit être traité comme un mot de passe.
• WebAuthn / passkeys : l’utilisateur s’enregistre avec un authentificateur cryptographique (plateforme ou clé de sécurité) lié à l’origine du site. Configurer les politiques WebAuthn/WebAuthn Passwordless, les exigences d’authentificateur et l’action d’enregistrement, puis insérer l’exécution dans le parcours approprié. Tester les navigateurs, appareils, secours et politique de récupération. Les intitulés et options diffèrent selon les versions.

Évitez d’imposer MFA sans prévoir la récupération de compte. Un flux de test trop permissif ne doit pas devenir celui de production.

Personnaliser sans se verrouiller dehors¶

Pour modifier un flux, commencez par le dupliquer dans la console du realm, donnez-lui un nom explicite et modifiez la copie. Assignez-la comme flux Browser ou à l’authenticator flow correspondant seulement après test. Conservez un compte administrateur de secours, testez les chemins réussite/échec, les utilisateurs sans OTP et les connexions fédérées, et gardez une procédure de retour arrière. Les flux intégrés peuvent recevoir des changements lors d’une mise à niveau ; privilégiez une copie gérée avec versionnement de configuration. Consultez le guide pratique.