Authentification du proxy par nom d’utilisateur et mot de passe : se connecter et éviter les erreurs

Avec l’authentification par nom d’utilisateur et mot de passe, votre application envoie au proxy les identifiants fournis par le prestataire. Le proxy les vérifie et vous autorise à utiliser le service. Cette méthode est utile lorsque vous travaillez depuis différents appareils et réseaux : si le service n’exige pas aussi une authentification par IP, le déplacement d’un script vers un autre serveur ne nécessite pas de modifier une adresse IP autorisée.

Une connexion fonctionnelle ne repose pas uniquement sur un nom d’utilisateur et un mot de passe. Il faut aussi renseigner l’adresse, le port et le protocole du proxy. Votre application doit prendre en charge la méthode d’authentification requise. Une erreur d’authentification ne signifie donc pas nécessairement que le mot de passe est incorrect.

Pour comparer les méthodes d’accès et choisir celle qui vous convient, consultez Authentification du proxy. Cet article explique comment se connecter avec un nom d’utilisateur et un mot de passe, de la saisie des paramètres au diagnostic des problèmes dans un script en cours d’utilisation.

En quoi consiste l’authentification par nom d’utilisateur et mot de passe ?

Le nom d’utilisateur identifie un compte ou l’accès à un service particulier, tandis que le mot de passe confirme votre droit de l’utiliser. Une fois la vérification réussie, le proxy traite la connexion dans le cadre des droits accordés : liste d’adresses disponible, quota acheté et limites applicables.

Il ne faut pas confondre les identifiants du proxy avec le mot de passe de votre espace client. Les informations utilisées par une application peuvent différer de celles qui permettent de se connecter au site du fournisseur. Une clé API sert à envoyer des requêtes à l’API du service, tandis que le mot de passe d’un site de destination sert à se connecter à ce site. N’utilisez l’un ou l’autre comme mot de passe du proxy que si le fournisseur prévoit explicitement cette méthode de connexion.

Une authentification réussie auprès du proxy ne vous connecte pas au site de destination. Si celui-ci exige un compte, des cookies ou un jeton, l’application doit toujours les fournir séparément.

Quand cette méthode est-elle utile ?

L’accès par nom d’utilisateur et mot de passe peut servir à des applications situées dans plusieurs lieux, fixes ou changeants. Sans restriction par IP, chaque application a besoin des identifiants et des paramètres de connexion au proxy, sans qu’il faille ajouter une entrée distincte pour son réseau dans la liste des adresses autorisées.

Par exemple, une équipe travaille depuis deux bureaux et des domiciles, chacun disposant d’une IP publique différente. Les applications peuvent utiliser les mêmes identifiants de proxy si le service autorise leur partage entre ces applications sans liaison à une IP. Chaque application conserve ses propres paramètres de connexion ; le proxy vérifie les identifiants envoyés par chacune.

Cette méthode convient aussi à plusieurs serveurs permanents. Le nombre d’appareils, de connexions simultanées et les ressources disponibles dépendent toutefois de l’offre. Un seul mot de passe ne donne pas un accès illimité.

Comment une application transmet-elle les identifiants du proxy ?

Le déroulement général est simple : l’application contacte le proxy, passe le contrôle d’accès et l’utilise pour atteindre la ressource demandée. Les détails dépendent du protocole.

Un proxy HTTP peut d’abord renvoyer 407 Proxy Authentication Required et indiquer la méthode d’authentification qu’il accepte. L’application envoie les informations d’authentification dans l’en-tête Proxy-Authorization. Certains clients les envoient immédiatement ; la demande initiale d’authentification peut donc ne pas apparaître dans le journal.

Lors de l’ouverture d’un site HTTPS via un proxy HTTP classique, l’authentification peut avoir lieu pendant la requête CONNECT qui établit un tunnel. L’application établit ensuite une connexion sécurisée avec le site. Les requêtes suivantes vers le site, qui empruntent ce tunnel déjà établi, ne répètent pas l’authentification auprès du proxy utilisée pour l’ouvrir.

Avec SOCKS5, le nom d’utilisateur et le mot de passe sont vérifiés au début de la connexion, avant la demande de connexion à la destination. Si la vérification échoue, l’application n’obtient pas la connexion demandée via le proxy. Un échec d’authentification natif SOCKS5 n’est pas une réponse HTTP 407.

Sélectionnez le protocole et la méthode d’authentification pris en charge par le service. SOCKS4 comporte un champ d’identifiant utilisateur, mais ne définit pas l’échange de nom d’utilisateur et de mot de passe propre à SOCKS5. Renseigner ce champ ne permet pas à un client SOCKS4 d’effectuer une authentification par mot de passe SOCKS5.

Quels paramètres saisir dans votre application ?

Partez des informations de connexion propres à votre service. Si l’application propose des champs distincts, saisissez chaque valeur dans le champ correspondant :

Certaines applications acceptent une seule chaîne au format protocol://username:password@host:port. Par exemple, dans http://client01:River%[email protected]:8080, le nom d’utilisateur est client01, le mot de passe River@2026, l’hôte proxy.example et le port 8080. Le caractère @ du mot de passe est représenté par %40 pour éviter de le confondre avec le séparateur placé avant l’hôte.

curl, par exemple, prend en charge cette interprétation d’une URL de proxy. Un champ de mot de passe distinct attend généralement le mot de passe lui-même, sans encodage URL. Ne copiez pas une valeur encodée depuis une URL dans un champ distinct sans vérifier le format : l’application pourrait la traiter comme un autre mot de passe. Pour les chaînes contenant %, des deux-points ou d’autres caractères spéciaux, suivez les exigences de format du client.

Encodez une seule fois les caractères nécessaires à l’intérieur des identifiants ; encoder toute la chaîne altérerait ses séparateurs. Mettre un argument de commande entre guillemets ne remplace pas l’encodage URL. La méthode d’authentification peut avoir ses propres restrictions : HTTP Basic, par exemple, autorise les deux-points dans le mot de passe, mais pas dans le nom d’utilisateur.

Les formats d’importation diffèrent eux aussi. host:port:username:password et username:password@host:port ne sont pas interchangeables. Des valeurs correctes placées dans le mauvais ordre ne fonctionneront pas si l’outil d’importation attend une autre disposition.

Le préfixe http:// d’une URL de proxy décrit la façon dont le client se connecte au proxy lui-même. Il n’empêche pas l’accès aux sites HTTPS : le client peut établir un tunnel pour les joindre. Remplacer simplement ce préfixe par https:// n’ajoute pas au serveur la prise en charge d’une connexion sécurisée au proxy.

Certains services incluent un pays, un groupe de sorties ou un paramètre de session dans le nom d’utilisateur. Copiez la chaîne entière. Ces paramètres contrôlent le routage selon les règles du fournisseur ; n’inventez pas leur syntaxe et ne reprenez pas celle d’un autre service.

Pourquoi vérifier la prise en charge de l’authentification dans l’application ?

La prise en charge d’un proxy et celle de son authentification sont deux capacités distinctes. La présence de champs pour l’hôte et le port ne signifie pas nécessairement que le client peut envoyer un nom d’utilisateur et un mot de passe.

Vérifiez la combinaison exacte du protocole du proxy, de la méthode d’authentification et de l’application. Par exemple, l’implémentation SOCKS5 intégrée à Chrome ne prend pas en charge l’authentification auprès d’un proxy SOCKS5. Des identifiants corrects ne suffisent pas à résoudre cette limitation. Une extension de sélection de proxys n’ajoute pas non plus nécessairement la méthode d’authentification manquante.

Dans les scripts, la prise en charge peut dépendre de la bibliothèque, de ses composants facultatifs et de la manière de fournir les paramètres. Une application n’utilise pas nécessairement les paramètres de proxy du système ou ceux d’un navigateur dans lequel la connexion fonctionne déjà.

Avant de lancer une tâche importante, testez une requête dans l’application qui l’exécutera. Vérifiez qu’elle utilise le proxy indiqué et ne poursuit pas avec une connexion directe après un échec. Le seul fait qu’une page se charge ne confirme pas que les paramètres sont corrects.

Que se passe-t-il lorsque votre IP change ?

Avec une connexion ADSL à IP dynamique, le fournisseur d’accès à Internet peut attribuer une nouvelle adresse après un redémarrage du routeur ou une reconnexion. Si le proxy vérifie uniquement un nom d’utilisateur et un mot de passe, l’application se connecte avec les mêmes identifiants : aucune nouvelle IP n’est à ajouter dans l’espace client. Il en va de même lors du passage du bureau au réseau du domicile.

Un changement de réseau peut toutefois interrompre les connexions existantes. Le client devra se reconnecter, et une requête inachevée pourra nécessiter une nouvelle tentative. Une erreur survenue juste après le passage du Wi-Fi à l’Internet mobile ne doit pas être automatiquement attribuée au mot de passe.

Certains services vérifient à la fois les identifiants et l’adresse source. Un mot de passe correct ne lève pas cette restriction réseau : la nouvelle IP doit correspondre à une adresse ou à une plage autorisée. Avant de déplacer un script, déterminez si le service accepte les connexions depuis n’importe quel réseau ou applique une vérification combinée.

Le mot de passe est-il protégé pendant son transfert ?

L’authentification détermine qui est autorisé à accéder au service. Le chiffrement détermine si quelqu’un situé sur le trajet peut lire les données transmises. La présence d’un mot de passe ne rend pas, à elle seule, la connexion chiffrée.

HTTP Basic encode le nom d’utilisateur et le mot de passe en Base64. Il s’agit d’une représentation réversible, pas d’un chiffrement. Sans protection de la connexion au proxy, une personne qui observe ce trajet réseau peut récupérer les identifiants. L’authentification standard SOCKS5 par nom d’utilisateur et mot de passe ne chiffre pas non plus leur transmission.

HTTPS sur le site de destination protège la connexion entre l’application et ce site. Avec un proxy HTTP, l’authentification effectuée pendant l’établissement du tunnel a lieu en amont ; la connexion TLS du site ne protège pas les identifiants du proxy déjà envoyés. De même, une requête HTTPS via SOCKS5 ne chiffre pas la vérification préalable du mot de passe du proxy.

Pour protéger cette portion du trajet, il faut une protection entre l’application et le proxy, comme un proxy HTTPS utilisant TLS, lorsque le service et le client le prennent tous deux en charge. L’application doit valider le certificat du proxy. Dans certaines offres commerciales, « proxy HTTPS » signifie uniquement que les sites HTTPS sont accessibles ; vérifiez donc où TLS s’applique réellement.

Si une chaîne de connexion complète contenant un mot de passe valide est divulguée, une autre personne peut être en mesure d’utiliser le service selon ses règles, en consommant le quota ou en occupant des connexions. Cela ne revient pas à obtenir le mot de passe de l’espace client si les identifiants sont distincts. La méthode d’authentification ne garantit pas non plus qu’une adresse ne puisse pas être identifiée comme un proxy : une demande d’authentification accessible de l’extérieur peut révéler le service.

Plusieurs applications peuvent-elles utiliser les mêmes identifiants ?

Techniquement, plusieurs clients peuvent envoyer le même nom d’utilisateur et le même mot de passe. Le fournisseur décide si cela est permis et en fixe le cadre : conditions de partage, limites de connexions actives, quota acheté et éventuelles restrictions supplémentaires.

Par exemple, deux scripts peuvent utiliser un même compte tout en ouvrant des nombres de connexions différents. Un mot de passe ne signifie pas une seule connexion. De même, lancer dix processus ne multiplie pas par dix le nombre total de connexions autorisées par le service.

Le nombre de paires d’identifiants est aussi distinct du nombre d’IP de sortie. Un seul nom d’utilisateur et un seul mot de passe peuvent donner accès à une liste de proxys statiques ou à une passerelle reposant sur un pool d’adresses. L’IP vue par le site dépend du proxy sélectionné et des règles de routage du service.

Si le service propose des identifiants distincts pour les applications ou les membres de l’équipe, vous pouvez en désactiver un jeu sans modifier les autres. Avec un mot de passe partagé, son remplacement impose de mettre à jour toutes les applications qui l’utilisent. Des identifiants distincts n’impliquent toutefois pas des quotas de connexions ou de trafic distincts : vérifiez les limites qu’ils partagent.

Pourquoi un proxy refuse-t-il un nom d’utilisateur et un mot de passe ?

Identifiez d’abord l’origine de l’erreur. Le code HTTP 407 concerne l’authentification auprès du proxy ; un code 401 provenant du site de destination concerne l’accès à ce site. Un message 403 ou un délai d’attente dépassé ne permet pas, sans autre élément, de savoir si le mot de passe du proxy est correct.

Vérifiez l’état du service et le quota restant, puis testez une requête avec les paramètres fournis dans l’application réellement utilisée. En cas d’échec, servez-vous du tableau pour vérifier la prise en charge par le client, le format des identifiants et les restrictions d’IP source, en ne modifiant qu’un paramètre à la fois. Une fois la requête fiable, augmentez la charge de travail et surveillez les limites qui n’apparaissent que sous charge.

Comment stocker et changer les identifiants dans les scripts utilisés ?

Conservez les identifiants séparément du code, dans une configuration à accès contrôlé ou dans le gestionnaire de secrets de votre environnement. Une application peut les recevoir par des variables d’environnement, mais celles-ci ne constituent pas en elles-mêmes un chiffrement. Ne placez pas de mots de passe actifs dans les dépôts et les modèles que vous partagez.

Un journal a généralement besoin de l’hôte et du port du proxy, du résultat de la connexion et du code d’erreur. Une chaîne de connexion complète contient le mot de passe ; masquez-le avant de l’inscrire dans le journal. Avec les outils en ligne de commande, tenez compte du fait qu’un secret peut rester dans l’historique des commandes ou être visible dans les arguments du processus, selon l’application et le système.

Avant de changer un mot de passe, recensez tous ses utilisateurs : applications locales, processus serveur, tâches planifiées et systèmes de compilation. Après la modification, mettez leurs paramètres à jour et établissez une nouvelle connexion pour les tester. Vérifiez que les processus de longue durée ont eux aussi pris en compte la nouvelle valeur ; certains doivent être redémarrés.

Si l’ancien mot de passe ne doit plus fonctionner, vérifiez qu’une nouvelle connexion l’utilisant est refusée. Les connexions existantes suivent les règles propres au service : un changement de mot de passe ne les ferme pas toujours immédiatement. Pour une révocation urgente, utilisez la méthode de désactivation de l’accès prise en charge par le fournisseur.

Authentification combinée : IP et mot de passe

Avec l’authentification combinée, le proxy vérifie deux conditions : les identifiants et l’adresse depuis laquelle l’application se connecte. Les deux doivent être satisfaites. Un mot de passe correct ne suffit pas à lever la restriction par IP.

Pour les offres statiques de ProxyCompass, le mode combiné utilise un sous-réseau /24. Si vous possédez plusieurs adresses IPv4 publiques dans le même sous-réseau, il suffit d’en ajouter une à la liste des adresses autorisées. Les autres adresses de ce sous-réseau peuvent se connecter avec le bon nom d’utilisateur et le bon mot de passe, sans entrée distincte pour chacune.

Dans l’illustration, l’IP publique de l’application partage les trois premiers nombres avec l’adresse autorisée. Elle peut se connecter avec des identifiants valides ; une adresse hors de ce sous-réseau échoue au contrôle réseau, et un mot de passe incorrect échoue même à l’intérieur de celui-ci. D’autres IP clientes du même sous-réseau peuvent aussi utiliser cette entrée. Cela est utile pour les applications qui exigent des champs de nom d’utilisateur et de mot de passe. Cette règle concerne les IP publiques de vos applications, pas les IP de sortie des proxys achetés.