Le fonctionnement de la connexion — authentification, session et Cookie

Cet article traite du fonctionnement de la connexion.

La connexion se compose de deux mécanismes : l'un vérifie que l'utilisateur est bien celui qu'il prétend être, l'autre permet de continuer à reconnaître cette même personne ensuite.

« Hachage », « authentification par session » et « JWT » désignent une seule et même fonction de connexion, nommée différemment selon le contexte.

La branche du haut est la vérification faite une seule fois ; celle du bas, la vérification faite à chaque requête ensuite.

L'authentification vérifie qui tu es, l'autorisation décide ce que tu peux faire

L'authentification (authentication ; vérifier que l'utilisateur est bien celui qu'il prétend être) est la décision prise au moment de la connexion.

L'autorisation (authorization ; décider ce que l'utilisateur vérifié a le droit de faire) est une autre décision, prise ensuite.

Même pour une action du même tanaka, les deux sont décidées séparément.

Certaines lignes s'arrêtent à l'authentification, d'autres la passent puis s'arrêtent à l'autorisation.

Les réglages du type « réservé aux administrateurs » ou « tu ne vois que tes propres données » relèvent de l'autorisation.

Vérifier qui tu es, c'est l'authentification ; décider ce que tu peux faire, c'est l'autorisation

Pouvoir se connecter et avoir le droit d'effectuer une opération sont deux choses décidées séparément.

L'authentification vérifie si l'utilisateur est bien celui qu'il prétend être, l'autorisation décide s'il a le droit d'effectuer cette opération, et l'autorisation est vérifiée côté serveur à chaque opération.

Le mot de passe est stocké sous forme de hachage, et ce sont les hachages que l'on compare

La première chose à retenir sur l'authentification, c'est que le serveur ne stocke pas le mot de passe lui-même.

Ce qui est stocké, c'est un hachage (hash ; chaîne produite à partir de la chaîne d'origine par une procédure fixe, et impossible à retransformer en l'original).

Un seul caractère de différence produit un hachage totalement différent.

La vérification reste possible bien que le hachage soit irréversible, parce que l'élément de comparaison est lui aussi un hachage.

Le serveur ne détient qu'une chaîne irréversible.

Le hachage sert à se prémunir contre une fuite du contenu de la base de données.

Les chaînes courantes se devinent, donc on ajoute avant le hachage une chaîne différente pour chaque utilisateur (un sel).

Le HTTPS de l'envoi empêche la lecture en cours de route ; c'est une question distincte de la forme de stockage.

Ce qui est stocké est un hachage, et l'élément de comparaison en est un aussi

Le serveur ne détient pas le mot de passe tapé par l'utilisateur.

Il ne détient qu'une chaîne irréversible : à chaque connexion, il fait passer les caractères tapés par la même procédure et vérifie si la chaîne obtenue est identique à celle qui est stockée.

Après la connexion, c'est l'ID de session du Cookie qui permet au serveur de reconnaître la même personne

Même après une connexion réussie, la requête qui ouvre la page suivante est une autre requête.

HTTP est sans état (stateless ; un échange ne garde pas la mémoire du précédent), donc le serveur ne retient pas qui vient de se connecter.

Le fait que la connexion a réussi est enregistré côté serveur, et le navigateur reçoit une chaîne qui pointe vers cet enregistrement.

L'enregistrement conservé côté serveur est la session (session), la chaîne qui pointe vers lui est l'ID de session (session ID), et le mécanisme qui confie cette chaîne au navigateur et la lui fait envoyer à chaque fois est le Cookie (cookie).

Côté navigateur, il n'y a que la chaîne 3f9a1c...e81b, sans nom ni droits.

À qui appartient la connexion n'apparaît que lorsque cette chaîne est reliée à l'enregistrement côté serveur.

Seule la ligne du haut est reliée à un enregistrement, donc la liste des réservations revient sans redemander le mot de passe.

Cet échange prend la forme des deux lignes suivantes.

# La ligne que le serveur renvoie quand la connexion réussit
Set-Cookie: session_id=3f9a1c...e81b; HttpOnly; Secure

# Ensuite, la ligne jointe à chaque requête que le navigateur envoie au même site
Cookie: session_id=3f9a1c...e81b

Les deux éléments après Set-Cookie sont des instructions pour le navigateur.

HttpOnly empêche le JavaScript de la page de lire ce Cookie, et Secure ne le fait envoyer qu'en HTTPS.

Le contenu d'un Cookie peut être modifié par l'utilisateur, donc le résultat change selon qu'on lui fait confiance ou non.

Le Cookie est stocké dans le navigateur, donc l'utilisateur peut en modifier le contenu avant de l'envoyer.

Ne mets dans le Cookie que l'ID de session, et prends la décision à partir de l'enregistrement côté serveur.

Dans le cadre de gauche, il n'y a qu'une chaîne sans signification propre.

Tout ce qui détermine qui est l'utilisateur et ce qu'il peut faire se trouve dans le cadre de droite.

Le navigateur ne reçoit qu'une seule chaîne, qui pointe vers l'enregistrement

Au moment où une requête arrive, le serveur ne sait pas de qui elle vient.

Il le sait parce que l'enregistrement créé à la connexion et la chaîne envoyée à chaque fois par le navigateur sont reliés ; si l'enregistrement est supprimé ou expire, envoyer la même chaîne ramène à l'écran de connexion.

Authentification par session et JWT — l'enregistrement est-il détenu par le serveur ou par la chaîne ?

« Authentification par session ou JWT » revient à choisir lequel des deux détient la preuve que tu es connecté.

L'autre approche ne laisse aucun enregistrement sur le serveur et confie la preuve elle-même au navigateur.

Cette chaîne de preuve jointe à chaque envoi est un jeton (token), et le JWT (JSON Web Token ; chaîne qui regroupe l'ID de l'utilisateur, une date d'expiration et une signature) en est le format le plus répandu.

Grâce à la signature, le serveur reconnaît que la chaîne reçue est bien celle qu'il a émise, sans la comparer à un enregistrement.

Le JWT porte son contenu, donc il est accepté sans enregistrement côté serveur.

Avec l'authentification par session, supprimer l'enregistrement suffit à bloquer la requête suivante.

Le JWT passe jusqu'à son expiration, donc pour l'arrêter tout de suite, on tient à part une liste des jetons révoqués.

Dans cet article, l'authentification par session a été représentée avec un Cookie et le JWT sous forme de chaîne, mais en pratique il existe aussi des configurations qui placent le JWT dans un Cookie.

Même si l'emplacement change, la différence reste la même : comparer à un enregistrement ou vérifier une signature.

Le serveur détient-il l'enregistrement, ou la chaîne porte-t-elle son contenu ?

Dans les deux approches, le navigateur joint et envoie une chaîne à chaque fois.

Ce qui diffère, c'est ce que fait le serveur à la réception : l'authentification par session consulte son propre enregistrement, le JWT vérifie la signature jointe à la chaîne.