Authorization

Utilisation

L’en-tête de requête Authorization permet d’obtenir l’accès à une ressource protégée ; il est généralement envoyé après que le client a été informé que l’accès est restreint. Par exemple, après avoir reçu du serveur une réponse HTTP 401 Unauthorized incluant l’en-tête WWW-Authenticate, le client soumet ses identifiants de cette manière.

Remarque

Les navigateurs suppriment l’en-tête Authorization lorsqu’une requête est redirigée vers une origine différente. Cela évite la fuite d’identifiants lorsqu’une redirection pointe vers un serveur tiers. Ce comportement est défini dans le WHATWG Fetch Standard et il est pris en charge par tous les navigateurs modernes. Les applications qui s’appuient sur des en-têtes Authorization à travers des redirections multi-origines doivent gérer une réauthentification à la destination finale. Des outils comme curl, Python Requests et le client HTTP de Go suivent la même convention.

authentication-scheme

Le authentication-scheme est une directive obligatoire, accompagnée de paramètres facultatifs propres au schéma. Le schéma définit la méthode d’encodage des identifiants. Les approches courantes incluent Basic, Bearer, Digest et Negotiate.

Exemple

Dans cet exemple, le client utilise le schéma d’authentification Basic. En tant que paramètre obligatoire, les identifiants sont une paire username:password encodée en base64.

Authorization: Basic RXhhbXBsZTphaQ==

Un jeton Bearer est courant avec les API OAuth 2.0. Le jeton est une chaîne opaque ou un JWT signé émis par un serveur d’autorisation.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Dépannage

Les échecs d’autorisation se manifestent souvent par des réponses 401 inattendues ou par des identifiants supprimés silencieusement.

Identifiants supprimés lors d’une redirection multi-origine. Les navigateurs et les clients HTTP retirent l’en-tête Authorization lorsqu’une requête est redirigée vers une origine différente. La solution consiste à envoyer les identifiants directement à la destination finale, ou à se réauthentifier une fois la redirection terminée. Inspectez les chaînes de redirection avec curl -L -v pour repérer où l’en-tête disparaît.

Erreurs d’encodage base64 en authentification Basic. La chaîne encodée doit contenir exactement un deux-points séparant le nom d’utilisateur et le mot de passe. Un deux-points manquant ou une valeur doublement encodée produit un jeton incohérent que le serveur rejette. Vérifiez la valeur brute avec echo -n “user:pass” | base64 et comparez-la à la valeur d’en-tête envoyée dans la requête.

Jeton Bearer expiré ou mal formé. Les jetons portent une revendication d’expiration, et les serveurs rejettent les jetons expirés avec un 401. Décodez un JWT sur jwt.io ou avec echo "" | base64 -d pour inspecter le champ exp. La logique de rafraîchissement du jeton doit s’exécuter avant l’expiration du jeton, et non après que le serveur a rejeté la requête.

Boucle de 401 lorsque le serveur omet WWW-Authenticate. Le serveur renvoie un 401 mais n’inclut pas l’en-tête WWW-Authenticate, ce qui laisse le client sans indication sur le schéma attendu. Examinez les en-têtes de réponse avec curl -I https://example.re/resource et vérifiez que la configuration du serveur inclut bien cet en-tête. Sous nginx, la directive auth_basic ajoute l’en-tête automatiquement. Les backends personnalisés doivent définir l’en-tête explicitement.

Le préflight CORS bloque l’en-tête Authorization. Les requêtes multi-origines portant un en-tête Authorization déclenchent une requête préflight OPTIONS. Le serveur doit répondre au préflight avec Access-Control-Allow-Headers: Authorization. Une valeur manquante ou incorrecte amène le navigateur à bloquer la requête avant l’envoi des identifiants. L’onglet Network des DevTools affiche le préflight comme une entrée OPTIONS distincte.

curl envoie les identifiants au mauvais point de terminaison. Exécuter curl -H “Authorization: Bearer …” avec -L suit les redirections mais supprime l’en-tête lors des sauts vers une autre origine. Utilisez curl -v sans -L pour envoyer l’en-tête au point de terminaison exact, ou passez —location-trusted pour forcer le transfert des identifiants à travers les redirections (à n’utiliser qu’avec prudence, sur des domaines de confiance uniquement).

Basic vs Bearer

Basic et Bearer sont les deux schémas d’authentification les plus courants et répondent à des cas d’usage différents.

Basic envoie à chaque requête une paire username:password encodée en Base64. L’encodage est trivialement réversible, ce qui rend HTTPS obligatoire. Les identifiants sont statiques et liés à un compte utilisateur : un mot de passe compromis impose donc de changer le mot de passe lui-même. Basic convient bien aux outils internes et aux intégrations simples, où la gestion de jetons ajouterait une complexité inutile.

Bearer utilise des jetons opaques (souvent des JWT) émis par un serveur d’autorisation. Les jetons expirent, portent des permissions délimitées et sont révocables sans changer le mot de passe sous-jacent. Bearer est le mécanisme standard pour les API et les flux OAuth 2.0. Un jeton volé a une durée de vie limitée et une portée limitée, ce qui réduit le rayon d’impact par rapport à un mot de passe divulgué.

Les deux schémas transmettent les identifiants en clair dans la valeur de l’en-tête. Aucun ne fournit de chiffrement par lui-même. HTTPS est requis quel que soit le schéma retenu.

Une requête API multi-origine avec un jeton Bearer utilisant la Fetch API.

fetch('https://api.example.re/data', {
  headers: {
    'Authorization': 'Bearer eyJhbGci...'
  }
})