HTTP 407 ou 401 : quelle connexion faut-il authentifier ?
Distinguez l’authentification du proxy de celle du site, examinez les bons en-têtes et évitez d’envoyer vos identifiants au mauvais intermédiaire.
Un 407 vous demande de vous authentifier auprès du proxy. Un 401 demande une authentification pour la ressource cible. Une même requête peut rencontrer les deux : identifiez le demandeur avant de fournir un mot de passe.
Comparer le statut et les en-têtes de demande d’authentification
| Réponse | En-tête de demande d’authentification | En-tête d’identifiants | Partie concernée |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | Un proxy intermédiaire |
| 401 Unauthorized | WWW-Authenticate | Authorization | Le mécanisme d’authentification de la ressource d’origine |
Le statut est un premier indice essentiel, mais examinez tout l’échange. Une page qui affiche 407 dans son texte n’équivaut pas à une véritable réponse HTTP 407. De même, une page de connexion personnalisée peut renvoyer 200 tout en exigeant une authentification au niveau de l’application.
Pourquoi une requête HTTPS peut échouer avec 407 avant d’atteindre le site
Lorsqu’un proxy HTTP ordinaire transporte une requête HTTPS, le client lui demande généralement d’abord d’établir un tunnel CONNECT. Le proxy peut demander une authentification pour cette requête CONNECT. Si elle n’aboutit pas, la session TLS avec la destination n’a pas encore été établie dans le tunnel. Changer le jeton API du site a donc peu de chances de réparer cette étape.
Utilisez une requête avec sortie détaillée pour situer la demande d’authentification :
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/Remplacez le point d’écoute local par le vôtre et lisez la première demande dans le journal. Un 407 pendant CONNECT précède le TLS de destination ; un 401 peut ensuite survenir après l’établissement réussi du tunnel.
Fournir les identifiants du proxy par l’interface prévue
Pour un point de connexion et un compte fournis par un administrateur de confiance, curl peut négocier le mécanisme d’authentification du proxy et demander le mot de passe manquant :
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/Remplacez le point de connexion et le nom d’utilisateur d’exemple par ceux du service que vous êtes autorisé à utiliser. Ne préciser que le nom d’utilisateur évite d’inscrire directement le mot de passe dans la commande ci-dessus. Les méthodes prises en charge peuvent varier selon le proxy et la compilation de curl ; si la négociation échoue, vérifiez la demande réelle et les capacités de cette compilation.
L’option d’authentification du proxy est distincte de l’option d’authentification de l’utilisateur auprès de l’origine dans curl. N’ajoutez pas d’en-tête Authorization destiné à l’origine pour répondre à une demande du proxy. Évitez aussi de transmettre manuellement les en-têtes d’identifiants du proxy à des requêtes sans rapport ou de les enregistrer dans des en-têtes réutilisés par toute l’application.
Si le proxy renvoie toujours 407
- Confirmez que vous utilisez le nom d’hôte et le port du proxy attendus.
- Vérifiez les mécanismes d’authentification annoncés par le proxy au lieu de présumer qu’il s’agit de Basic.
- Confirmez l’état du compte et l’éventuel format de nom d’utilisateur exigé par le service.
- Vérifiez la transmission des caractères spéciaux si les identifiants sont intégrés à une URL.
- Déterminez si l’authentification d’entreprise intégrée au navigateur nécessite une prise en charge du moteur d’exécution ou de la plateforme.
- Si les éléments côté client sont insuffisants, demandez à l’administrateur un identifiant de requête ou une entrée de journal serveur expurgés des données sensibles.
Un 403 ou un CONNECT refusé peut résulter d’une politique d’accès même après une connexion réussie. Réessayer davantage de mots de passe ne donnera pas accès à une destination interdite.
Le HTTPS de destination ne protège pas tous les échanges d’identifiants du proxy
L’authentification du proxy peut intervenir avant l’établissement du TLS de destination. Si la connexion au proxy lui-même est en clair et que la méthode expose des identifiants réutilisables sur ce lien, une cible HTTPS ne protège pas rétroactivement cet échange. Choisissez un transport et une méthode d’authentification adaptés au service, et n’envoyez pas de comptes personnels à un proxy public inconnu.
Relisez les journaux détaillés avant de les partager. Même si un outil masque les champs d’identifiants courants, ils peuvent encore contenir des noms d’utilisateur, des noms de points de connexion internes, des cookies ou d’autres données identifiantes.