L’authentification a pour but d’identifier un client à un serveur. Nous distinguons plusieurs types d’authentification sur le web, principalement : à base de username / password (HTTP Basic Auth), à base de token (OAuth2 / JWT), ou à base de session (cookie). Nous allons aujourd’hui voir l’authentification par session.
Cette authentification est stateless (sans état), ce qui permet aux serveurs de ne pas garder d’information sur les clients (chaque requête est indépendante). Très utile pour REST. Sécure que si HTTPS est utilisé (TLS over HTTP) pour chiffrer les headers qui contiennent le username et mot de passe en clair (https://www.baeldung.com/spring-security-basic-authentication).
Ce sujet a déjà été vu sur le projet Cars : Step 8 - Ajout de l’authentification
Cette authentification est utile lorsque plusieurs applications doivent vérifier l’identité d’un même client : chaque application ne peut pas avoir une copie du mot de passe! Un serveur central vérifie l’identité, retourne un token, qui peut-être validé que par les applications qui ont validé ce serveur central (https://www.baeldung.com/spring-security-oauth2-jws-jwk).
Ce sujet a déjà été vu avec Frank : application people
Cette authentification est “historique” et très simple : lorsque le serveur authentifie un utilisateur avec son mot de passe, il génère un session id pour cet utilisateur qu’il lui retourne. Ce “session id” est renvoyé au serveur à chaque requête grâce aux cookies (les cookies sont renvoyés automatiquement à chaque requête pour un domaine donné, https://www.tutorialspoint.com/javascript/javascript_cookies.htm). Le serveur ne vérifie que le session id. Cela permet aussi d’associer à un session id du contenu ! Par exemple un utilisateur a vu tel nombre de page, etc. Le session id est stocké en mémoire, sur disque, dans un cache, ou en BDD.
Pour faire les exercies, exécuter npm install
dans ce dossier, pour installer Express et quelques utilitaires.
req.session
pour acceder a la sessionreq.session.destroy