Authentification HTTPL'authentification HTTP ou identification HTTP (spécifiée par RFC 2617[1]) permet de s'identifier auprès d'un serveur HTTP en lui montrant que l'on connaît le nom d'un utilisateur et son mot de passe, afin d'accéder aux ressources à accès restreint de celui-ci. Fonctionnement généralLorsqu'un client HTTP demande une ressource protégée au serveur, celui-ci répond de différente façon selon la requête :
MéthodesIl existe deux méthodes définies par la spécification RFC 2617[1] :
Méthode « Basic »Cette méthode est la plus simple, mais également la moins sécurisée car elle transmet le mot de passe codé en base 64 qui se décode aisément. Elle n'est recommandée qu'avec une connexion chiffrée (protocole HTTPS). Le serveur ne recevant pas d'en-tête d'identification correcte envoie ce genre d'en-tête HTTP : WWW-Authenticate: Basic realm="WallyWorld" Le serveur indique la méthode requise (Basic), suivie des paramètres. La méthode « Basic » ne requiert que le paramètre « realm » identifiant le domaine de protection. Le client HTTP peut alors réessayer la requête en spécifiant l'en-tête HTTP « Authorization ». Celui-ci doit contenir la méthode utilisée (Basic) suivie de la représentation en Base64 du nom de l'utilisateur et du mot de passe séparés par le caractère « : » (deux-points). Par exemple, pour authentifier l'utilisateur « Aladdin » avec le mot de passe « open sesame », le client envoie : Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Méthode « Digest »Cette méthode ne transmet pas le mot de passe en clair, mais impose de stocker celui-ci (ou son hachage SHA1, qui suffit pour s'identifier et peut donc être considéré comme un mot de passe) en clair. Même si cette méthode est plus sûre que la méthode « Basic », elle reste tout de même sensible aux attaques (interception de communication…), et plus sensible encore à certaines attaques (vol de fichier de mots de passe). La méthode « Digest » est plus complexe et emploie plus de paramètres. Demande d'identificationLe serveur peut envoyer une demande d'identification du genre : WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth, auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Les paramètres sont séparés par une virgule et sont les suivants :
Identification du clientLe client s'identifiant avec la méthode « Digest » utilise deux fonctions pour calculer certains paramètres : H(data) = MD5(data) La fonction H retourne sous la forme d'une chaîne de caractères (format hexadécimal, en minuscule) le résultat de la fonction de hashage MD5. Elle peut également utiliser un autre algorithme de hashage (SHA par exemple). L'algorithme employé est spécifié dans le paramètre « algorithm ». KD(secret, data) = H(secret:data) La fonction KD appelle la fonction H avec comme argument la concaténation des deux paramètres secret et data séparés par le signe deux-points. Le client envoie donc l'en-tête « Authorization » contenant le nom de la méthode « Digest » suivi des paramètres :
Le calcul de la valeur du paramètre Si response = KD( H(A1), Sinon : response = KD( H(A1),
Si A1 = si A1 = H( Si A2 = si A2 =
Réponse du serveurLe serveur recalcule les mêmes valeurs que le client pour vérifier si l'identification est réussie. Dans le cas où le serveur répond positivement (utilisateur et mot de passe corrects), il envoie, dans la réponse, l'en-tête HTTP « Authentication-Info » contenant des informations sur l'identification réussie et la prochaine identification. Cet en-tête contient également une liste de paramètres séparés par une virgule :
Identification sur serveur mandataire (Proxy)L'identification décrite ci-dessus se déroule entre l'utilisateur et le serveur d'origine: Il est également possible de s'identifier auprès des serveurs intermédiaires :
Pour cela, les en-têtes HTTP Proxy-Authenticate et Proxy-Authorization sont utilisés à la place des en-têtes WWW-Authenticate et Authorization. Le code d'état HTTP 407 est utilisé au lieu du code 401. L'en-tête Proxy-Authentication-Info a le même rôle que l'en-tête Authentication-Info. Un client peut devoir s'identifier à la fois à un proxy et au serveur d'origine, mais pas dans la même réponse. L'identification ne peut être utilisée dans le cas d'un proxy transparent Notes et référencesVoir aussiArticles connexesLiens externes |
Portal di Ensiklopedia Dunia