Flux d'authentification utilisateur : inscription à une session validée

Un flux d'authentification des utilisateurs sur un canevas interactif : création de compte, hachage et stockage des informations d'identification, connexion, création de session et validation des demandes protégées.

Un flux d'authentification utilisateur est le chemin depuis la création d'un compte jusqu'à ce que chaque demande ultérieure soit approuvée : les informations d'identification sont hachées avant le stockage, vérifiées lors de la connexion, et un jeton de session remplace ensuite le mot de passe.

Flux d'authentification utilisateur : inscription à une session validée

Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.

Comment lire ce visuel

  • Lisez les trois colonnes de gauche à droite : Inscription, Connexion, Session.
  • Les quatre voies sont les acteurs, et le mot de passe ne quitte jamais les trois premières : seuls les hachages atteignent la voie Base de données.
  • Le message « Le hachage correspond-il à celui stocké ? » La décision divise la connexion en chemin de session et le rejet « Connexion refusée ».

S'inscrire

Flux « L'utilisateur crée un compte » et « Le client envoie un e-mail et un mot de passe » « Le service d'authentification hache le mot de passe » : au moment où le mot de passe cesse d'être récupérable. "Les informations d'identification hachées sont stockées dans la base de données" marque la fin de l'inscription : la base de données contient désormais un hachage salé, et son commentaire explique que le service ne peut pas récupérer le texte en clair, ce qui est le but du hachage.

Connectez-vous

"L'utilisateur se connecte avec ses informations d'identification" et "Le client les transmet au service d'authentification" répètent la première moitié du parcours, et "Le hachage correspond à celui stocké ?" est la vérification : le mot de passe entrant est haché de la même manière et comparé. La branche « Non » se termine par « Connexion refusée » ; la branche "Oui" procède à la création de la session.

Session

"Le service d'authentification crée une session" émet le jeton qui remplace le mot de passe, "Le client stocke le jeton de session" le déplace vers le client et "Les requêtes protégées portent le jeton ; le serveur le valide" est l'état stable du système : chaque requête protégée fait ses preuves avec le jeton. "Accès accordé pour la session" ferme le flux : l'utilisateur est authentifié pour la durée de la session, pas pour une seule requête.

Relations et enseignements clés

  • Les mots de passe sont hachés avant le stockage : la base de données contient un hachage unidirectionnel salé, jamais le texte brut.
  • La connexion compare les hachages, de sorte que le service d'authentification lui-même ne peut pas récupérer le mot de passe stocké.
  • Le jeton de session remplace le mot de passe pour les requêtes ultérieures, ce qui rend l'authentification pratique à grande échelle.
  • Le stockage et la vérification sont des préoccupations distinctes dans des voies différentes, chacun pouvant donc être protégé séparément.
  • Le flux a la même forme, que le jeton soit une session serveur ou un JWT : voir le visuel JWT pour la mécanique du jeton.

Quand utiliser ce visuel

  • Enseigner à une nouvelle équipe la forme sécurisée de l’authentification avant de concevoir sa première connexion.
  • Révision d'un flux d'authentification pour les failles classiques : stocker le texte en clair, comparer le texte en clair, faire confiance au client.
  • Ancrer une conversation sur l'authentification multifacteur et son lien avec le flux.

Comment cela fonctionne

  1. Renommez les acteurs de votre système

    Remplacez l'application client et le service d'authentification par vos composants réels (votre application Web, votre fournisseur d'identité) et ajoutez ceux qui manquent au diagramme générique.

  2. Ajouter une authentification multifacteur

    Insérez une étape MFA lors de la connexion, entre la vérification du hachage et la création de la session, avec une branche pour la vérification du deuxième facteur.

  3. Afficher le chemin de réinitialisation du mot de passe

    Ajoutez une branche de réinitialisation à la décision de connexion (mot de passe oublié, jeton de réinitialisation, définition d'un nouveau mot de passe), chacune se terminant par un état explicite.

  4. Annoter le cycle de vie du jeton

    Sur la zone de session, notez les règles d'expiration, de révocation et d'actualisation de votre jeton, et créez un lien vers le visuel JWT si vous émettez des JWT.

Questions fréquentes

Quel est le moyen sécurisé de stocker les mots de passe ?

Ne stockez jamais le mot de passe lui-même. Stockez un hachage salé (une fonction unidirectionnelle appliquée au mot de passe plus un sel aléatoire) et supprimez le texte en clair. Lors de la connexion, hachez le mot de passe entrant de la même manière et comparez les hachages. Si la base de données fuit, l'attaquant obtient des hachages qu'il ne peut pas inverser, ce qui est exactement la propriété pour laquelle les boîtes de hachage du visuel existent.

Quelle est la différence entre le hachage et le cryptage ?

Le cryptage est réversible : avec la clé vous pouvez récupérer la valeur originale. Le hachage est à sens unique : il n'y a pas de clé ni de retour. Pour les mots de passe que vous souhaitez hacher, car vous n'avez plus jamais besoin du texte en clair, seulement de la possibilité de vérifier. Le visuel indique « hachage » plutôt que « crypte » pour cette raison ; le cryptage des mots de passe est une confusion courante et dangereuse.

Comment un jeton de session remplace-t-il le mot de passe ?

Après une connexion réussie, le service d'authentification crée une session et remet au client un jeton (une valeur aléatoire ou un JWT signé) qui représente l'utilisateur authentifié. Les requêtes protégées portent le jeton et le serveur le valide au lieu de demander à nouveau le mot de passe. C’est ce qui rend l’authentification pratique pour les requêtes répétées, et c’est pourquoi l’expiration du jeton constitue la véritable limite de sécurité.

Quelle est la place de l’authentification multifacteur dans ce flux ?

MFA est un contrôle supplémentaire lors de la connexion, après la vérification du mot de passe et avant la création de la session : l'utilisateur fournit un deuxième facteur : un code à usage unique, une application d'authentification, une clé matérielle. La colonne de connexion du visuel est l'endroit où cette étape se connecte. MFA ne modifie pas les mécanismes de hachage ou de session ; il place la barre plus haut sur la seule décision, "Le hachage correspond à celui stocké ?", en ajoutant une deuxième preuve.

Modifier ce visuel dans QueryChart (FlowJam)

Ouvrez ce canevas d'authentification exact en tant que votre propre graphique, renommez les acteurs de votre système et ajoutez vos véritables contrôles.

Modifier ce visuel dans QueryChart (FlowJam)

Plus dans Explications visuelles