L’authentification HTTP

HTTP fournit un cadre général pour le contrôle d’accès et l’authentification, via un ensemble extensible de schémas d’authentification de type « défi-réponse », qui peuvent être utilisés par un serveur pour contester une requête client et par un client pour fournir des informations d’authentification.

 

Fonctionnement général de l’authentification HTTP

HTTP utilise un jeton (token) insensible à la casse comme moyen d’identifier le schéma d’authentification, suivi des informations supplémentaires nécessaires pour réaliser l’authentification via ce schéma. Ce dernier peut être soit une liste de paramètres séparés par des virgules, soit une seule séquence de caractères capable de contenir des informations codées en base64.

Les paramètres d’authentification sont des paires nom = valeur.

Un message de réponse 401 (Unauthorized) est utilisé par un serveur d’origine pour contester l’autorisation d’un agent utilisateur. Ce message contient un champ d’en-tête WWW-Authenticate contenant au moins un défi applicable à la ressource demandée.

Un message de réponse 407 (Proxy Authentication Required) est utilisé par un proxy pour contester l’autorisation d’un client. Ce message contient un champ d’en-tête Proxy-Authenticate contenant au moins un challenge applicable au proxy pour la ressource demandée.

Un agent utilisateur qui souhaite s’authentifier auprès d’un serveur d’origine – généralement, mais pas nécessairement, après avoir reçu un 401 (non autorisé) – peut le faire en incluant un champ d’en-tête Authorization avec la requête.

Un client qui souhaite s’authentifier avec un proxy – généralement, mais pas nécessairement, après avoir reçu un 407 (authentification proxy requise) – peut le faire en incluant un champ d’en-tête Proxy-Authorization avec la requête.

La valeur du champ Authorization et celle du champ Proxy-Authorization contiennent les informations d’identification du client pour le realm (l’espace de protection) de la ressource demandée, en fonction d’un défi reçu dans une réponse.

À la réception d’une requête d’accès à une ressource protégée qui omet les informations d’identification, contient des informations d’identification non valides (par exemple, un mauvais mot de passe) ou des informations d’identification partielles (par exemple, lorsque le schéma d’authentification nécessite plus d’un aller-retour), un serveur d’origined evrait envoyer une réponse 401 contenant un champ d’en-tête WWW-Authenticate avec au moins un (éventuellement nouveau) défi applicable à la ressource demandée.

De même, à la réception d’une demande qui omet les informations d’identification de proxy ou contient des informations d’identification de proxy non valides ou partielles, un proxy qui requiert une authentification devrait générer une réponse 407 contenant un champ d’en-tête Proxy-Authenticate avec au moins un (éventuellement nouveau) défi applicable au proxy.

Un serveur qui reçoit des informations d’identification valides mais qui ne sont pas suffisantes pour accéder à une réponse doit répondre avec le code de statut 403 (Forbidden).

 

Les codes de statut 401 et 407 en détail

Le code de statut 401 indique que la requête n’a pas été satisfaite car il manque des informations d’identification d’authentification valides pour la ressource cible. Le serveur générant une réponse 401 doit envoyer un champ d’en-tête WWW-Authenticate (section 4.1) contenant au moins un défi applicable à la ressource cible.

Si la requête incluait des informations d’authentification, la réponse 401 indique que l’autorisation a été refusée pour ces informations. L’agent utilisateur PEUT répéter la demande avec un champ d’en-tête Authorization nouveau ou remplacé.

Le code de statut 407 est similaire au code 401 mais il indique que le client doit s’authentifier pour utiliser un proxy. Le mandataire doit envoyer un champ d’en-tête Proxy-Authenticate contenant un défi applicable à ce mandataire pour la ressource cible. Le client peut répéter la demande avec un champ d’en-tête Proxy-Authorization nouveau ou remplacé.

 

Les en-têtes de réponse WWW-Authenticate et Proxy-Authenticate

Les en-têtes de réponse WWW-Authenticate et Proxy-Authenticate définissent la méthode d’authentification à utiliser pour accéder à une ressource. Ils doivent spécifier le schéma d’authentification utilisé, afin que le client qui souhaite autoriser sache comment fournir les informations d’identification. La syntaxe de ces en-têtes est la suivante:

WWW-Authenticate: type realm = realm
Authentification proxy: type realm = realm

Ici, « type » est le schéma d’authentification (« Basic » est le schéma le plus courant). Le realm est utilisé pour décrire la zone protégée ou pour indiquer l’étendue de la protection. Il peut s’agir d’un message du type « Accès à l’espace réservé » ou similaire, afin que l’utilisateur sache à quel espace il tente d’accéder.

 

Les en-têtes de requête Authorization et Proxy-Authorization

Les en-têtes de requête Authorization et Proxy-Authorization contiennent les informations d’identification pour authentifier un agent utilisateur avec un serveur ou un proxy. Ici, le type est à nouveau nécessaire suivi des informations d’identification, qui peuvent être encodées ou chiffrées selon le schéma d’authentification utilisé.

Authorization: type credentials
Proxy-Authorization: type credentials

 

Le schéma d’authentification Basic et la sécurité

Dans le cas d’une authentification avec un schéma Basic, l’échange doit avoir lieu via une connexion HTTPS (TLS) pour être sécurisé.

Le schéma d’authentification HTTP Basic transmet les informations d’identification sous forme de paires ID utilisateur / mot de passe, codées en base64. Comme l’ID utilisateur et le mot de passe sont transmis sur le réseau en texte clair (il est codé en base64, mais en base64 est un codage réversible), le schéma d’authentification de base n’est pas sécurisé. HTTPS / TLS doit être utilisé conjointement avec l’authentification de base. Sans ces améliorations de sécurité supplémentaires, l’authentification de base ne doit pas être utilisée pour protéger des informations sensibles ou précieuses.

Pour protéger par mot de passe un répertoire sur un serveur Apache, vous aurez besoin d’un fichier .htaccess et d’un fichier .htpasswd.

Le fichier .htaccess ressemble généralement à ceci:

AuthType Basic
AuthName "Accès à l’espace protégé"
AuthUserFile /path/to/.htpasswd
Require valid-user

Le fichier .htaccess fait référence à un fichier .htpasswd dans lequel chaque ligne se compose d’un nom d’utilisateur et d’un mot de passe séparés par deux points (« : »). Vous ne pouvez pas voir les mots de passe réels car ils sont cryptés (md5 dans ce cas).

Pour nginx, vous devrez spécifier un emplacement que vous allez protéger et la directive auth_basic qui fournit le nom de la zone protégée par mot de passe. La directive auth_basic_user_file pointe ensuite vers un fichier .htpasswd contenant les informations d’identification utilisateur chiffrées, tout comme dans l’exemple Apache ci-dessus.

 

Le schéma d’authentification Basic en détail

L’un des piliers du schéma d’authentification Basic est que le client doit s’authentifier lui-même avec un identifiant utilisateur et un mot de passe pour chaque espace de protection (« realm »).

La valeur du realm est une chaîne de forme libre qui ne peut être comparée que pour égalité avec d’autres realm sur ce serveur. Le serveur ne traitera la demande que s’il peut valider l’ID utilisateur et le mot de passe pour l’espace de protection s’appliquant à la ressource demandée.

Le schéma d’authentification de base utilise le cadre d’authentification comme suit.

Dans les défis:

• Le nom du schéma est « Basic » ;
• Le paramètre d’authentification «realm » est obligatoire ;
• Le paramètre d’authentification « charset »’ est facultatif ;
• Aucun autre paramètre d’authentification n’est défini. Les paramètres inconnus doivent être ignorés par les destinataires.

À la réception d’une demande d’URI dans l’espace de protection qui manque d’informations d’identification, le serveur peut répondre avec un défi en utilisant le code de statut et le champ d’en-tête WWW-Authenticate comme ceci :

HTTP/1.1 401 Unauthorized
Date: Tue, .04 févr.2020 18:00:00 GMT
WWW-Authenticate: Basic realm="Formations”

« Formations » est la chaîne affectée par le serveur pour identifier l’espace de protection. Notez qu’un proxy peut répondre avec un défi similaire en utilisant le code de statut 407.

Pour recevoir l’autorisation, le client :

1. Obtient l’identifiant et le mot de passe de l’utilisateur ;
2. Concatène l’ID utilisateur et le mot de passe et les séparant par un deux-points (:) ;
3. Encode le résultat en une séquence d’octets ;
4. Obtient les informations d’identification Basic en encodant cette séquence d’octets à l’aide de Base64 en une séquence de caractères US-ASCII ;

Notez que le schéma d’authentification Basic n’est pas une méthode sécurisée d’authentification des utilisateurs, ni ne protège en aucune façon l’entité, qui est transmise en texte clair sur le réseau physique utilisé comme opérateur.

L’authentification Basic entraîne notamment la transmission en texte clair du mot de passe de l’utilisateur sur le réseau physique. Cette la raison pour laquelle on l’utilise avec des améliorations comme HTTPS pour protéger les informations sensibles ou précieuses.