Authentification Basic

Introduction

Bien que peu sûre (voir les limitations), l'authentification Basic est le mécanisme d'authentification HTTP le plus utilisé. Elle permet de vérouiller (i.e. protéger par login/mot de passe) assez simplement tout ou partie d'un site web.

On peut reconnaître très facilement l'authentification Basic : dès que l'on navigue sur un site web et qu'une fenêtre comme celle-ci s'ouvre pour demander au visiteur de s'authentifier, on se retrouve avec une authentification Basic :

Principe et fonctionnement

Notion de royaume

Avant d'entrer dans les détails, l'authentification HTTTP (Basic et Digest) s'appuie sur la notion de royaume (realm en anglais). Un royaume est une zone identifiée (ou nommée) à laquelle un utilisateur ne pourra accéder que s'il fournit une authentification valide. Prenons l'exemple d'un immeuble de bureaux utilisant des badges. Pour rentrer dans l'immeuble, vous devez passer par l'accueil. C'est un premier royaume "visiteurs" : vous devez présenter votre carte d'identité et indiquer le nom de la personne que vous venez voir. On vous donne alors un badge visiteur et vous pouvez vous déplacer à peu près librement dans l'immeuble. Les seuls endroits où vous ne pouvez pas aller sont des zones réservées aux employés. C'est un second royaume "réservé au personnel" dans lequel seul les porteurs de badges employés peuvent entrer. La notion de royaume est importante car elle détermine les zones protégées et les domaines de validité authentifications. Par exemple, avec l'authentification Basic, un couple de login/mot de passe ne sera valide que pour un royaume A. Si vous vous rendez sur une page faisant partie du royaume B, vous devrez renseigner un nouveau login/mot de passe.

Fonctionnement de l'authentification Basic

Passons maintenant au fonctionnement de l'authentification HTTP Basic. elle s'appuie sur deux en-têtes HTTP (WWW-Authenticate et Authorization) et un statut (401) :

1. Le client fait une requête sur le serveur web.
2. Le serveur s'aperçoit que la page demandée par le client est une page protégée par authentification HTTP Basic. En outre, le client n'a pas fourni de login/mot de passe. Le serveur renvoie alors une réponse (possédant évnetuellement un corps contenant un document expliquant pourquoi une authentification est nécessaire) avec un statut 401 (Authorization Required) et un en-tête WWW-Authenticate pour demander à l'utilisateur de s'authentifier :
   WWW-Authenticate: Basic realm="Personnel seulement"
   Cet en-tête indique le type d'authentification requis (Basic, donc) et le royaume (realm).
3. Le navigateur reçoit la réponse demandant une authentification pour le royaume. Supposons que l'utilisateur ne s'est pas encore authentifié pour ce royaume. Le navigateur ouvre alors une petite fenêtre comme celle déjà vue pour permettre à l'utilisateur de s'authentifier pour le royaume donné.
   
4. l'utilisateur entre un login et un mot de passe et clique sur OK.
5. Le navigateur refait la requête initiale en ajoutant un en-tête Authorization contenant la chaîne "login:mot_de_passe" encodé en base64. Par exemple, si le login/mot de passe est "titi/toto", le navigateur enverra l'en-tête suivant ("dGl0aTp0b3Rv" correspond à l'encodage en base64 de la chaîne "titi:toto") :
   Authorization: Basic dGl0aTp0b3Rv
6. Le serveur reçoit cette nouvelle requête. Il voit qu'elle concerne une ressource protégée mais on fournir une authentification (en-tête Authorization). Le serveur examine donc cette authentification. Si elle est valide, il renvoie la ressource demandée. Sinon, il renvoie de nouveau une réponse avec une statut 401.
7. Si le navigateur reçoit de nouveau une réponse 401, il est libre de proposer de nouveau à l'utilisateur de rentrer un login/mot de passe. Mais il peut également afficher un message d'erreur ou le document renvoyé par le serveur avec sa réponse 401. C'est généralement ce qu'il se passe lorsque l'authentification échoue trois fois de suite.
8. Pour les requêtes suivantes concernant des ressources se trouvant dans la sous-arborescence du premier document demandé, le navigateur retransmettra le login/mot de passe valide. En effet, la RFC2617 définissant l'authentification Basic, l'autorise à considérer que les documents se trouvant dans la même sous-arborescence sont protégés par le même login/mot de passe, sans attendre que le serveur demande une authentification. Si d'aventure un autre login/mot de passe est nécessaire, le serveur répondra par un statut 401 pour demander une nouvelle authentification. Par exemple, si le document initial ayant conduit à une authentification HTTP est /chemin1/fichier1.html, le navigateur considérera que les fichiers /chemin1/fichier2.html et /chemin1/chemin2/fichier3.html sont protégé par le même mot de passe que /chemin1/fichier1.html, ce qui ne sera pas le cas de /chemin3/fichier4.html.

Limitations de l'authentification Basic

L'authentification HTTP est très simple à mettre en place (par exemple, avec Apache, il suffit de configurer des fichiers .htaccess et des fichiers de mots de passe ; pas besoin de base de données ou de serveur LDAP), mais elle présente un certain nombre de limitations qu'il convient de connaître et prendre en compte avant de mettre en place ce mécanisme de sécurité :

• Pas de mécanisme de "déconnection" : lorsqu'on s'est authentifié une fois, on reste authentifié jusqu'à ce qu'on ferme le navigateur.
• Authentification peu sécurisée : l'encodage base64 est facile à inverser (bien que l'utilisation du SSL (HTTPS) permette de renforcer fortement la sécurité globale de la partie protégée du site, y compris l'authentification)
• Authentification HTTP Basic passe nécessairement par la fenêtre popup vue dans l'introduction. Il n'est pas possible de mettre en place une page de login personnalisée.

Remarque concernant le statut 403

Parfois, le serveur renvoie une réponse avec un statut 403 (Forbidden). Cela signifie que la ressource demandée est inaccessible à tous. Une tentative d'authentification ne changera donc rien à cette situation bloquante.

Références

Les RFCs :

• RFC1521 : MIME (Multipurpose Internet Mail Extensions). Défini l'encodage base64 (paragraphe 5.2).
• RFC2616 : HTTP/1.1
• RFC2617 : authentification par les méthodes Basic et Digest

Vous pouvez également tester l'encodeur/décodeur base64 de TmP (écrit en JavaScript).

 format imprimable