Erreur HTTP 401 Unauthorized : signification et solutions

Qu'est-ce que l'erreur 401 Unauthorized ?

Une erreur 401 Unauthorized signifie que le serveur exige une preuve de votre identité, et que votre requête n'en a pas fourni, ou que les identifiants envoyés ont été rejetés. Pas de mot de passe, un mauvais mot de passe, un token expiré ou une clé d'API manquante : tout se termine de la même façon.

La norme HTTP la définit comme une requête qui « n'a pas d'identifiants d'authentification valides pour la ressource cible », et un serveur qui envoie un 401 DOIT inclure un en-tête WWW-Authenticate indiquant le schéma de connexion qu'il accepte (RFC 9110 §15.5.2).

Autrement dit, le serveur demande « Qui êtes-vous ? » avant de vous laisser entrer.

À quoi ressemble une erreur 401

La page que vous voyez dépend du serveur et de l'application :

• 401 Unauthorized — la ligne de statut standard, et la formulation de la plupart des applications
• 401 Authorization Required — le titre de la page 401 intégrée à nginx, avec « nginx » (en général suivi de sa version) en dessous (code source de nginx) ; les anciens serveurs Apache 2.2 emploient les mêmes mots
• Unauthorized · This server could not verify that you are authorized to access the document requested — la page par défaut d'Apache
• 401 - Unauthorized: Access is denied due to invalid credentials — IIS ; la page détaillée (affichée uniquement sur le serveur lui-même) et le journal IIS donnent la raison sous la forme 401.1, 401.2 ou 401.3 : échec de connexion, configuration du serveur ou autorisations sur les fichiers
• Une boîte de connexion dans le navigateur — quand le serveur demande une authentification HTTP Basic ou Digest, ou (sur IIS et les intranets d'entreprise) NTLM ou Negotiate
• This page isn't working · HTTP ERROR 401 — Chrome, quand la réponse 401 n'a pas de page à elle
• Du JSON renvoyé par une API, par exemple {"error":{"message":"Missing Authentication header","code":401}}

Les navigateurs n'affichent la boîte de connexion que pour ces schémas d'authentification. Les API à token (« Bearer ») ne la déclenchent jamais : leur 401 revient en JSON, que l'application traite. Les sites avec un formulaire de connexion envoient en général le visiteur déconnecté vers la page de connexion avec une redirection 302 plutôt qu'avec un 401.

« 401 Authorization Required » sur nginx

Ce titre vient de la page 401 intégrée à nginx. Vous l'obtenez quand un emplacement est protégé par auth_basic et que la requête ne contenait ni nom d'utilisateur ni mot de passe, ou des identifiants erronés ; annuler la boîte de connexion du navigateur affiche aussi cette page.

En tant que visiteur, rechargez la page et saisissez le nom d'utilisateur et le mot de passe que le propriétaire du site vous a donnés. Ils sont distincts de tout compte sur le site : l'authentification Basic vérifie un fichier de mots de passe sur le serveur.

En tant que propriétaire du site, voici comment la protection se met en place, et comment garder un chemin public :

# Create the password file (htpasswd comes with apache2-utils or httpd-tools)
#   sudo htpasswd -c /etc/nginx/.htpasswd alice   # -c creates the file: leave it out when adding users

location /admin/ {
    auth_basic           "Admin area";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

# Inside a protected server block, open one path to everyone
location /public/ {
    auth_basic off;
}

# Test, then reload
#   curl -I -u alice:PASSWORD https://example.com/admin/
#   sudo nginx -t && sudo systemctl reload nginx

Toujours un 401 avec le bon mot de passe ? Vérifiez que l'utilisateur figure dans le fichier (htpasswd -c écrase le fichier et supprime les utilisateurs précédents) et que l'application derrière nginx n'a pas elle aussi besoin de l'en-tête Authorization : la connexion Basic de nginx et les tokens Bearer d'une application utilisent tous deux cet en-tête, si bien que l'application reçoit les identifiants de nginx et les rejette.

401 vs 403 : quelle est la différence ?

Les codes 401 et 403 sont souvent confondus. En bref : 401 signifie « je ne sais pas qui vous êtes », tandis que 403 signifie « je ne vous laisse pas entrer », que votre identité soit ou non le problème.

Une règle pratique : si fournir le bon nom d'utilisateur et mot de passe (ou clé API) résoudrait le problème, le serveur devrait retourner 401. Si l'utilisateur est déjà authentifié mais n'a simplement pas accès à cette ressource, le serveur devrait retourner 403 Forbidden.

Causes courantes des erreurs 401

Les causes, du côté du visiteur jusqu'à celui du serveur :

• Mauvais nom d'utilisateur ou mot de passe — la cause la plus simple, surtout après une réinitialisation du mot de passe
• Token d'authentification expiré — les JWT, les tokens d'accès OAuth et les cookies de session ont tous une durée de vie
• En-tête Authorization manquant — la requête ne contenait aucun identifiant
• Clé d'API invalide — la clé a été révoquée, renouvelée ou mal copiée
• Mauvais schéma d'authentification — le serveur attend un token Bearer mais reçoit une authentification Basic, ou l'inverse
• Décalage d'horloge — le serveur qui vérifie un JWT et celui qui l'a émis (ou votre machine, si c'est elle qui le signe) ne sont pas d'accord sur l'heure ; de nombreuses bibliothèques n'acceptent aucune tolérance
• Une requête préliminaire CORS — la vérification OPTIONS du navigateur ne transporte jamais d'identifiants, donc un serveur qui en exige répond 401 et la vraie requête n'est jamais envoyée
• Une session périmée — le navigateur envoie un cookie de session que le serveur a déjà terminée
• Un intermédiaire supprime l'en-tête — Apache cache Authorization à PHP-FPM et aux scripts CGI sauf configuration contraire, CloudFront le retire des requêtes GET et HEAD par défaut, et l'authentification Basic de nginx devant une application le récupère
• Identifiants verrouillés ou révoqués — trop de tentatives échouées peuvent verrouiller un compte (certaines API répondent alors plutôt par 429 Too Many Requests)

Comment corriger l'erreur 401 en tant que visiteur

Si vous rencontrez une erreur 401 sur un site web auquel vous essayez d'accéder, le problème est presque toujours lié à vos identifiants de connexion. Suivez ces étapes dans l'ordre.

1. Vérifiez vos identifiants de connexion

La cause la plus courante d'une erreur 401 est simplement des identifiants incorrects. Si le site affiche une fenêtre contextuelle ou un formulaire de connexion, vérifiez votre nom d'utilisateur et votre mot de passe.

Erreurs courantes : le verrouillage des majuscules est activé, vous utilisez un ancien mot de passe (surtout après une réinitialisation récente), ou vous vous connectez au mauvais compte. Si vous avez un gestionnaire de mots de passe, laissez-le remplir automatiquement les identifiants pour éviter les fautes de frappe.

2. Videz le cache et les cookies du navigateur

Votre navigateur envoie peut-être un cookie de session expiré. Supprimer les cookies du site l'oblige à demander une nouvelle connexion.

Dans Chrome en français, ouvrez « Supprimer les données de navigation » avec Ctrl+Maj+Suppr (Cmd+Maj+Suppr sur Mac), choisissez la période « Toutes les données » au lieu de « Dernière heure », cochez « Cookies et autres données des sites » et « Images et fichiers mis en cache », puis cliquez sur « Supprimer les données ». Vous serez déconnecté de tous les sites. Pour un seul site : à côté de l'adresse, « Afficher des informations à propos du site » → « Cookies et données des sites » → « Gérer les données des sites sur l'appareil ». Les étapes pour les autres navigateurs (libellés anglais) :

Chrome, Edge, Firefox: Ctrl+Shift+Delete (Cmd+Shift+Delete on a Mac)
  → Time range: All time → Cookies and site data + Cached files → Delete / Clear
  (this signs you out of every site; the per-site option below doesn't)
Safari: Settings → Privacy → Manage Website Data → the site → Remove
One site in Chrome: the icon left of the address → Site settings → Delete data

Après avoir vidé le cache, fermez complètement le navigateur (pas seulement l'onglet), rouvrez-le et naviguez à nouveau vers la page. Vous devriez voir une nouvelle invite de connexion.

3. Essayez le mode navigation privée

Ouvrez l'URL dans une fenêtre de navigation privée (Chrome) ou privée (Firefox/Safari). Cela contourne tous les cookies en cache, les extensions et les identifiants enregistrés.

Si la page fonctionne en navigation privée mais pas dans votre navigateur normal, le problème est un cookie en cache ou une extension du navigateur qui interfère avec l'authentification. Désactivez les extensions une par une pour trouver la coupable.

4. Vérifiez l'URL

Assurez-vous de visiter la bonne URL. Certains serveurs renvoient un 401 pour des chemins qui exigent une authentification, même si le chemin lui-même est faux. Vous essayez peut-être d'accéder à une zone réservée qui ne vous est pas destinée.

Vérifiez s'il existe une version publique de la page à une autre URL. Par exemple, example.com/admin/ peut renvoyer 401 alors que example.com/ est accessible publiquement.

Vous n'êtes pas sûr que le site fonctionne ? Le Vérificateur de site en panne l'ouvre depuis 11 endroits, ce qui permet de distinguer un problème de connexion d'une panne.

Comment corriger l'erreur 401 en tant que développeur

Pour les développeurs travaillant avec des API, les erreurs 401 concernent généralement l'en-tête Authorization, le format du token ou le cycle de vie des identifiants. Voici les corrections les plus courantes.

5. Vérifiez l'en-tête Authorization

L'erreur de développeur la plus courante est un en-tête Authorization mal formé. Quand le serveur envoie un en-tête WWW-Authenticate, il indique le schéma attendu ; beaucoup d'API JSON (celles de GitHub et d'OpenRouter, par exemple) l'omettent et expliquent le problème dans le corps de la réponse.

Vérifiez que votre en-tête respecte le format exigé. Les schémas les plus courants sont Bearer (pour les tokens) et Basic (nom d'utilisateur:mot de passe encodé en Base64).

# Bearer token authentication (most APIs)
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIs..." https://api.example.com/data

# Basic authentication (username:password in Base64)
curl -u "username:password" https://api.example.com/data
# Equivalent to:
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

# Common mistakes that cause 401:
# Missing "Bearer " prefix:  Authorization: eyJhbGci...  ← WRONG
# Extra space:               Authorization: Bearer  eyJ... ← many servers reject it
# Wrong scheme:              Authorization: Basic eyJhbGci... ← WRONG

Lisez ensuite l'en-tête WWW-Authenticate de la réponse 401 : il indique le schéma que le serveur attend. Le Vérificateur d'en-têtes HTTP de DNS Robot affiche la réponse complète.

6. Vérifiez la validité de la clé API

Les clés d'API cessent de fonctionner quand la clé est renouvelée ou révoquée, que le compte est suspendu ou rétrogradé, ou qu'une clé de test est utilisée en production. (Une limite de débit répond 429, et une clé sans accès à un point d'accès reçoit généralement 403.)

Vérifiez que la clé est toujours active dans le tableau de bord du fournisseur, puis testez-la directement :

# Test a key: print only the status code (a real GET; some APIs reject HEAD)
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer YOUR_API_KEY" https://api.example.com/me
# 200 = the key works
# 401 = the key is missing, wrong, revoked or expired
# 403 = the key works but isn't allowed to use this endpoint

# Common slips:
# 1. A space or newline after the key in .env:   API_KEY="abc123 "
# 2. The test key in production, or the reverse
# 3. An empty variable, so the header is just "Authorization: Bearer"

7. Gérez l'expiration et le renouvellement des tokens

Les JWT et les tokens d'accès OAuth ont une durée de vie limitée, généralement de 15 minutes à 24 heures. À l'expiration, chaque appel d'API renvoie 401 jusqu'à ce que vous obteniez un nouveau token.

Si vous avez un token de rafraîchissement (OAuth 2.0 et la plupart des configurations JWT), échangez-le contre un nouveau token d'accès ; sinon, reconnectez-vous.

# Read a JWT's payload (tokens use base64url, so plain base64 -d often fails)
python3 -c 'import sys,base64,json; p=sys.argv[1].split(".")[1]; print(json.dumps(json.loads(base64.urlsafe_b64decode(p+"==")),indent=2))' "$TOKEN"
# "exp" is a Unix timestamp; compare it with: date +%s

# OAuth 2.0: get a new access token with the refresh token
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=YOUR_REFRESH_TOKEN" \
  -d "client_id=YOUR_CLIENT_ID"

8. Corrigez les problèmes de CORS preflight

Quand une page web appelle une API d'un autre domaine avec un en-tête Authorization, le navigateur envoie d'abord une requête préliminaire OPTIONS, et cette requête ne transporte jamais d'identifiants. Si le serveur exige une authentification sur OPTIONS, il répond 401, la requête préliminaire échoue et le navigateur signale une erreur CORS : la vraie requête n'est jamais envoyée.

La solution : laisser passer les requêtes OPTIONS sans authentification sur les points d'accès compatibles CORS.

# Nginx — allow OPTIONS requests without auth
location /api/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin https://app.example.com;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        add_header Access-Control-Allow-Headers "Authorization, Content-Type";
        add_header Access-Control-Max-Age 86400;
        return 204;
    }

    # CORS header on every other answer, the 401 included, or the browser reports a CORS error
    add_header Access-Control-Allow-Origin https://app.example.com always;

    # Normal auth for other methods
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Comment corriger l'erreur 401 en tant que propriétaire du site

Si vos visiteurs ou utilisateurs signalent des erreurs 401, le problème se trouve dans la configuration d'authentification de votre serveur. Effectuez ces vérifications.

9. Vérifiez la configuration d'authentification du serveur

Vérifiez que l'authentification n'est activée que sur les routes qui en ont besoin. Une erreur courante consiste à protéger un répertoire ou un site entier alors que seuls certains chemins devraient exiger une connexion.

Sur nginx, vérifiez vos directives auth_basic ; sur Apache, AuthType et Require. Sur Node.js/Express, vérifiez l'ordre des middlewares : un app.use(auth) enregistré avant vos routes publiques les protège elles aussi, donc enregistrez les routes publiques d'abord ou attachez l'authentification uniquement au routeur protégé.

# Nginx — WRONG: protects everything, including public pages
server {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # All pages now require login — including your homepage!
}

# Nginx — CORRECT: only protect admin routes
server {
    location / {
        # Public — no auth required
    }
    location /admin/ {
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

10. Vérifiez les règles d'authentification du .htaccess

Sur Apache, les fichiers .htaccess peuvent activer l'authentification Basic ou Digest pour un répertoire. Si un répertoire public contient un .htaccess avec les directives AuthType et Require, chaque visiteur reçoit une invite de connexion 401.

Cherchez les fichiers .htaccess dans le répertoire concerné et dans tous ses répertoires parents — Apache applique les règles de chaque .htaccess présent dans le chemin.

# Find all .htaccess files with auth rules
find /var/www/html -name '.htaccess' -exec grep -l 'AuthType\|AuthUserFile\|Require valid-user' {} \;

# Example .htaccess that causes 401 for everyone:
# AuthType Basic
# AuthName "Restricted Area"
# AuthUserFile /etc/apache2/.htpasswd
# Require valid-user

# Fix: remove auth lines from public directories,
# or move them to the specific /admin/.htaccess only

11. Vérifiez que l'en-tête Authorization atteint votre application

Le client envoie les bons identifiants, mais l'application ne les voit jamais. Où l'en-tête se perd :

nginx transmet Authorization au backend par défaut, donc aucune ligne supplémentaire n'est nécessaire ; mais si le même emplacement utilise auth_basic, la connexion de nginx s'approprie l'en-tête (voir la section nginx ci-dessus). Apache cache Authorization à PHP-FPM et aux scripts CGI tant que vous n'activez pas CGIPassAuth (Apache 2.4.13+), la cause classique des 401 dans les API WordPress et Laravel derrière Apache.

# Apache 2.4.13+ (inside a <Directory> block, or .htaccess): pass Authorization to PHP-FPM and CGI
CGIPassAuth On

# Older Apache: copy it into an environment variable instead
SetEnvIf Authorization "(.+)" HTTP_AUTHORIZATION=$1

Déboguer les erreurs 401 avec les en-têtes HTTP

Le moyen le plus rapide de diagnostiquer un 401 est de lire la réponse : l'en-tête WWW-Authenticate, quand le serveur l'envoie, indique quelle connexion il veut, et les API JSON expliquent généralement l'erreur dans le corps.

Utilisez le Vérificateur d'en-têtes HTTP de DNS Robot (si le 401 n'apparaît qu'après une redirection, le Vérificateur de redirections montre quelle étape le renvoie), ou curl dans un terminal :

# Print the response headers of a real GET
curl -sS -D - -o /dev/null https://api.example.com/protected-endpoint

# A 401 often carries one of:
# WWW-Authenticate: Bearer realm="api", error="invalid_token"
# WWW-Authenticate: Basic realm="Admin Area"

# It tells you:
# - the scheme (Bearer, Basic, Digest, Negotiate)
# - the realm (which area is protected)
# - for Bearer tokens, the error: invalid_request, invalid_token or insufficient_scope

Si WWW-Authenticate indique Bearer, il vous faut un token ; s'il indique Basic, un nom d'utilisateur et un mot de passe. error="invalid_token" signifie que le token est expiré, révoqué, mal formé ou invalide pour une autre raison. Pas d'en-tête du tout ? Lisez le corps de la réponse : beaucoup d'API y indiquent la raison.

L'erreur 401 affecte-t-elle le SEO ?

Un 401 sur une page publique la retire de Google. Google traite tous les codes 4xx sauf 429 de la même façon : le robot signale que le contenu n'existe pas, et une URL indexée est supprimée (documentation de Google sur l'exploration).

Les 401 sur des pages qui doivent exiger une connexion (panneaux d'administration, tableaux de bord, API) sont normaux : Google ne pénalise pas un site pour cela. N'utilisez simplement pas 401 ou 403 pour ralentir Googlebot ; selon Google, ils n'ont aucun effet sur la fréquence d'exploration.

Le problème, c'est un 401 sur des pages qui devraient être publiques, le plus souvent à cause d'une authentification appliquée à tout le site, ou d'une règle de CDN ou de proxy qui demande des identifiants sur des chemins publics.

Comment prévenir les erreurs 401

La prévention vous épargne le débogage ultérieur. Suivez ces pratiques pour minimiser les erreurs 401 dans vos applications et sites web.

• Mettre en place le renouvellement automatique des tokens — utilisez des tokens de rafraîchissement pour obtenir discrètement de nouveaux tokens d'accès avant l'expiration des anciens
• Définir des périmètres d'authentification précis — ne protégez que les routes qui ont vraiment besoin d'une authentification, laissez les pages publiques ouvertes
• Écrire des messages d'erreur clairs — renvoyez un corps d'erreur JSON utile avec le 401, pas seulement le code de statut
• Surveiller les échecs d'authentification — configurez des alertes sur les pics de réponses 401, qui peuvent révéler des problèmes d'identifiants ou des attaques
• Synchroniser les horloges des serveurs — utilisez NTP pour garder tous les serveurs à quelques secondes d'UTC et éviter les rejets de JWT dus au décalage d'horloge
• Tester avec le Vérificateur d'en-têtes HTTP — vérifiez régulièrement que les pages publiques renvoient 200 et que les pages protégées renvoient 401 comme prévu
• Documenter votre schéma d'authentification — indiquez clairement le format attendu de l'en-tête Authorization dans la documentation de votre API
• Gérer la requête préliminaire CORS — autorisez toujours les requêtes OPTIONS sans authentification sur les points d'accès de l'API