RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication ¶
Dans la série de RFC sur le protocole HTTP 1.1, ce nouveau document normalisait l’authentification faite en HTTP.
Le RFC 9110 l’a remplacé depuis.
Le HTTP originel avait été conçu uniquement pour de l’accès à des documents publics. Toutefois, l’authentification a été assez vite ajoutée, afin de permettre de mettre en ligne des documents dont l’accès est restreint à une certaine catégorie d’utilisateurs.
HTTP dispose aujourd’hui de plusieurs mécanismes d’authentification, décrits dans ce RFC. Il faut quand même noter que tous ont des limites et, qu’en pratique, l’authentification des utilisateurs humains se fait presque toujours par des mécanismes non-HTTP, et pas par ceux de ce RFC.
Le principe de base de l’authentification HTTP est le défi/réponse.
Un client cherche à accéder à une ressource non-publique : le serveur lui envoie à la place un défi (code de réponse 401 et en-tête WWW-Authenticate:), le client fait une nouvelle demande, avec la réponse au défi (en-tête Authorization:).
À noter qu’il n’y a pas que les serveurs d’origine qui peuvent exiger une authentification, les relais peuvent le faire également (la réponse de défi est alors un 407 et la réponse du client est dans un en-tête Proxy-Authorization:).
Les codes de retour liés à l’authentification (301 et 307) sont décrits en détail dans la section 3 et stockés dans le registre IANA des codes de retour.
…
L’authentification auprès d’un relais, est identique, avec Proxy-Authenticate: et Proxy-Authorization: au lieu de WWW-Authenticate: et Authorization:.
Les différents mécanismes d’authentification (comme Basic) sont notés dans un registre IANA. Le registre inclut un lien vers la spécification de chaque mécanisme. Ainsi, le traditionnel Basic est dans le RFC 7617 et le récent Bearer dans le RFC 6750. Si vous voulez enregistrer un nouveau mécanisme, lisez aussi le RFC 7236 pour voir des exemples.
Tout nouveau mécanisme doit tenir compte des caractéristiques de HTTP. Par exemple, comme HTTP est sans état, le serveur ne doit pas avoir à se souvenir des requêtes précédentes : toutes les informations pour authentifier un client doivent être dans la requête.
La section 6 résume les problèmes de sécurité liés à l’authentification.
Par exemple, le cadre général d’authentification de HTTP, spécifié dans ce RFC 7235, ne précise pas de mécanisme assurant la confidentialité des lettres de créance présentées. Ainsi, dans le cas du mécanisme Basic, le mot de passe est transmis en clair (on ne peut pas considérer Base64 comme un chiffrement…) Il faut donc prendre des précautions supplémentaires (TLS…) Notez qu’il n’y a pas que le mot de passe qui soit une donnée sensible : dans le cas de Basic, l’identificateur de l’utilisateur est également confidentiel.
Le mécanisme HTTP d’authentification, reposant sur un protocole sans état, ne fournit pas de durée de vie de l’authentification.
Un client peut garder le mot de passe éternellement alors que le serveur voudrait, par exemple, obliger les clients qui avaient été absents longtemps à se ré-authentifier. Et si c’est le client qui veut annuler l’effet de son authentification, le mécanisme HTTP ne permet pas de fonction de « déconnexion ».
C’est une des principales raisons pour lesquelles les applications qui authentifient les utilisateurs ne se servent pas souvent de l’authentification HTTP. Une autre raison est l’impossibilité d’adapter le dialogue de login, par exemple en mettant un lien vers une page de documentation. En pratique, la plupart des applications se servent donc d’un formulaire Web pour demander le mot de passe, puis d’un cookie (RFC 6265) pour chaque requête.