Authentification et gestion de session avec HTTP

Le protocole HTTP qui s’appuie sur TCP est un protocole client/serveur dans lequel les requêtes sont traitées indépendamment les unes des autres. Il s’agit d’un protocole non connecté, appelé aussi « sans état » (stateless protocol). Cette limitation est pénalisante pour certaines applications web qui ont besoin :

• de reconnaître les requêtes provenant du même utilisateur,
• d’associer un profil à l'utilisateur,
• de prendre en compte l’historique des requêtes lors de leur traitement,
• ….

Les applications ayant de tels besoins contournent donc cette limite via des techniques permettant une authentification et une gestion des états (le « session tracking », c'est à dire le suivi de session).

Le but de cet article est de présenter les techniques d’authentification et de suivie de session les plus utilisées avec HTTP. Le mois prochain un second article traitera des évolutions des navigateurs ou du protocole HTTP qui permettent d’améliorer le suivi de session.

Authentifications HTTP

S’il est vrai que la RFC 2616 spécifiant le protocole HTTP pose les bases d’un protocole sans état, la RFC 2617 spécifie deux méthodes d’authentification.
Ces méthodes dans lesquelles les identifiants d’authentification sont transmis du client vers le serveur via les entêtes HTTP sont :

• l’authentification HTTP Basic
• l’authentification HTTP Digest

Nous allons présenter brièvement ces deux méthodes.

L’authentification HTTP Basic

Cette méthode est la plus simple et la moins sécurisée. Il est fortement recommandé de l’utiliser uniquement avec une connexion HTTPS et de préférence avec une vérification des certificats de bout en bout (côté client et serveur).

Le client assure un suivi de session authentifiée en envoyant le nom et le mot de passe de l'utilisateur, encodé en base64, dans chaque requête qu'il envoie au serveur.

Remarques :

• Cette méthode d'authentification est particulièrement sensible à une écoute du trafic.
  En effet, une personne malveillante capable de récupérer la représentation base64 des identifiants d'une victime peut ensuite usurper l'identité de cette dernière auprès du serveur.
• Pour ne pas avoir à demander son nom et son mot de passe à l'utilisateur à chaque envoi de requête, les navigateurs mettent ces informations en cache.

L’authentification HTTP Digest

Cette méthode implémente un mécanisme de type "challenge/réponse " dans lequel le serveur et le client partagent un secret.
Pour chaque requête le serveur envoie un challenge au client qui envoie en retour une valeur calculée depuis le challenge et le secret partagé.
Le serveur fait le même calcul de son côté et compare les deux résultats pour s'assurer qu'il est bien en communication avec le client légitime.

Ce mécanisme a l'avantage :

• d'empêcher le rejeu de requêtes qui seraient lues par une personne malveillante, puisqu'à chaque requête le challenge change,
• de protéger les utilisateurs des serveurs malveillants ou compromis en ne fournissant pas les identifiants aux serveurs.

Remarque : Comme dans le cas de l'authentification HTTP Basic, pour ne pas avoir à demander son nom et son mot de passe à l'utilisateur à chaque envoi de requête, les navigateurs mettent ces informations en cache. 

La gestion de session via des cookies

C'est sans doute la plus utilisée des techniques de gestion des sessions utilisateur dans les applications web.

Pour rappel, un cookie est une chaîne de caractères qui figure dans les entêtes des requêtes et des réponses HTTP afin de conserver des informations lors de l'accès à différentes pages d'un site web ou lorsqu'un utilisateur retourne ultérieurement sur ce site web.
Ces informations sont conservées par le client, en mémoire (on parle de cookies de session), ou sur un disque dur (cookies permanents).
Le mécanisme des cookies est décrit dans la RFC 2965, "HTTP State Management Mechanism" (Mécanisme de gestion d'état HTTP).

Les cookies permanents sont fréquemment utilisés par des sites marchands pour mémoriser les préférences de leurs utilisateurs. Mais une autre utilisation courante des cookies est la gestion de session.

Une session débute par le processus d'authentification suivant :

• l'utilisateur saisit ses identifiants (nom/mot de passe) dans un formulaire HTML,
• les identifiants sont envoyés au serveur qui les contrôle,
• si ces identifiants sont corrects le serveur active un cookie pour suivre la session dans le navigateur de l'utilisateur,
• ce cookie sera échangé et contrôlé entre le client et le serveur tout au long de la session,
• lorsque l'utilisateur se déconnecte ou que la session expire, le serveur envoie un cookie de session vide au navigateur de l'utilisateur.

Remarques :

• Les données associées à la session sont stockées sur le serveur en utilisant la valeur du cookie comme un index.
• La valeur du cookie est généralement choisie aléatoirement.

Pour en savoir plus :

• Article de Wikipédia sur les cookies : http://en.wikipedia.org/wiki/HTTP_cookie#Session_management
• Article de Wikipédia sur l'authentification http : http://fr.wikipedia.org/wiki/HTTP_Authentification
• RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1) : http://www.ietf.org/rfc/rfc2616.txt
• RFC2617 (HTTP Authentication: Basic and Digest Access Authentication) : http://www.ietf.org/rfc/rfc2617.txt
• RFC2965 (HTTP State Management Mechanism) : http://www.ietf.org/rfc/rfc2965.txt