401 Unauthorized

Utilisation

Lorsqu’une erreur 401 Unauthorized arrive, le client comprend que des identifiants de connexion valides sont nécessaires avant que l’accès à la ressource demandée ne soit accordé. Le client doit d’abord se connecter, ou fournir des identifiants dans le cadre de la requête HTTP. Les identifiants existants envoyés avec la requête ne sont pas valides non plus. Ce statut se distingue de 403 Forbidden, qui informe le client que l’action n’est pas autorisée quels que soient les identifiants.

Remarque

Le nom « Unauthorized » est historiquement trompeur. 401 signifie que le client n’est pas authentifié : les identifiants sont absents ou invalides. Les utilisateurs authentifiés qui n’ont pas la permission d’effectuer l’action demandée reçoivent 403 Forbidden à la place. Cette dénomination perdure depuis la spécification HTTP/1.0 d’origine.

Lorsque le serveur envoie une réponse 401 Unauthorized, l’en-tête de réponse WWW-Authenticate est inclus. Il informe le client des méthodes d’autorisation permises. L’IANA maintient une liste de schémas d’authentification standard, dont la sécurité et la popularité varient. Schémas d’authentification courants :

Basic

Transmet les identifiants sous forme de paires ID/mot de passe.

Bearer

Également appelée authentification par jeton, elle repose sur des jetons de sécurité générés par le serveur et renvoyés au client après une connexion réussie. Le client envoie ces jetons dans les requêtes suivantes pour accéder aux ressources sécurisées. Le serveur inclut les détails de l’erreur lorsque c’est nécessaire : WWW-Authenticate: Bearer error=“invalid_token”, error_description=“Token expired”.

Digest

Un protocole défi-réponse utilisé pour authentifier les requêtes de ressources.

HOBA

Abréviation de HTTP Origin-Bound Authentication, un schéma qui n’exige pas que le serveur stocke les mots de passe, ce qui le rend résistant aux attaques par hameçonnage.

Mutual

Également appelée authentification bidirectionnelle, similaire aux schémas basic et digest, à la différence que le serveur est assuré de connaître le mot de passe chiffré du client. Le client et le serveur s’authentifient mutuellement avant que l’interaction ne se poursuive.

AWS4-HMAC-SHA256

Un algorithme d’authentification qui fournit les informations d’authentification à Amazon Web Services AWS S3 API Reference.

Plusieurs méthodes d’authentification peuvent être indiquées par le serveur sur plusieurs lignes ou sur une seule ligne séparée par des virgules. Lorsque le client dispose des identifiants requis, ceux-ci sont envoyés au moyen de l’en-tête de requête Authorization.

Impact SEO

Les moteurs de recherche comme Google n’indexent pas une URL qui renvoie un statut 401 Unauthorized. Les URL précédemment indexées qui renvoient ce code de statut sont retirées des résultats de recherche. Les pages renvoyant ce code ne gaspillent pas de budget d’exploration. N’utilisez pas 401 pour ralentir Googlebot. Seul 429 réduit la fréquence d’exploration.

Exemple

Le client demande une ressource et le serveur répond 401 Unauthorized pour indiquer que la ressource est protégée. Le serveur indique qu’il prend en charge à la fois les autorisations Basic et Mutual. Le client répond avec une paire username:password selon le protocole d’authentification Basic, indiquée dans l’en-tête Authorization. Le serveur transmet ensuite la ressource demandée.

Requête initiale

GET /documents/tech-news HTTP/1.1
Host: example.com

Réponse initiale

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Documents"
WWW-Authenticate: Mutual

Requête suivante, incluant Authorization

GET /documents/tech-news HTTP/1.1
Host: example.com
Authorization: Basic RXhhbXBsZTphaQ==

Réponse finale

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 25000

<PDF document included in message body>

Comment corriger

Un 401 Unauthorized signifie que le serveur exige des identifiants valides avant d’accorder l’accès.

Vérifiez l’en-tête WWW-Authenticate dans la réponse. Cet en-tête précise le schéma d’authentification attendu (Basic, Bearer, Digest, etc.). Alignez la requête du client sur le schéma requis. Ouvrez les DevTools du navigateur, sélectionnez l’onglet Network et cherchez l’entrée WWW-Authenticate sous Response Headers.

Vérifiez les identifiants. Confirmez que le nom d’utilisateur et le mot de passe, la clé d’API ou le jeton bearer sont corrects. Une seule faute de frappe ou un seul caractère d’espacement dans la valeur de l’en-tête Authorization entraîne un rejet. Testez les identifiants isolément avec curl -H “Authorization: Bearer ” pour écarter les problèmes au niveau applicatif.

Confirmez que le jeton n’a pas expiré. Les jetons bearer et les jetons de session ont une durée de vie limitée. Décodez un JWT dans un débogueur local pour vérifier la revendication exp. Régénérez ou rafraîchissez le jeton d’accès auprès du fournisseur d’authentification.

Faites correspondre le format de l’en-tête Authorization au schéma. Basic attend une paire username:password encodée en Base64. Bearer attend une chaîne de jeton brute. Un format incorrect déclenche un 401 même avec des identifiants valides. Une erreur fréquente consiste à omettre le préfixe du schéma (envoyer le jeton seul sans Bearer ).

Régénérez les identifiants si nécessaire. Effectuez une rotation de la clé d’API ou demandez un nouveau jeton au serveur d’autorisation. Des identifiants révoqués ou invalidés produisent toujours ce statut.

Videz le cache du navigateur et les Cookies. Des cookies de session obsolètes ou des en-têtes Authorization mis en cache entrent en conflit avec des identifiants mis à jour. Effacez les données stockées et authentifiez-vous à nouveau.

Vérifiez la configuration d’authentification côté serveur. Les fichiers .htpasswd d’Apache, les directives auth_basic de nginx et les règles AuthType de .htaccess contrôlent l’accès. Vérifiez que le chemin du fichier d’identifiants, le nom du realm et l’entrée utilisateur existent. Dans nginx :

auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;

Dans Apache :

AuthType Basic
AuthName "Restricted"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Vérifiez les portées OAuth et les revendications d’audience. Un jeton d’accès avec des identifiants corrects mais des portées erronées, ou une revendication aud ne correspondant pas au serveur de ressources, déclenche malgré tout un 401. Confirmez que le jeton est émis pour l’API cible.

Références de code

.NET

HttpStatusCode.Unauthorized

Rust

http::StatusCode::UNAUTHORIZED

Rails

:unauthorized

http.StatusUnauthorized

Symfony

Response::HTTP_UNAUTHORIZED

Python3.5+

http.HTTPStatus.UNAUTHORIZED

Java

java.net.HttpURLConnection.HTTP_UNAUTHORIZED

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_UNAUTHORIZED

Angular

@angular/common/http/HttpStatusCode.Unauthorized