Générateur d'en-tête Basic Auth

Comment générer un en-tête Basic Auth

1. Saisissez le Nom d’utilisateur et le Mot de passe.
2. Laissez Jeu de caractères sur UTF-8, sauf si le serveur est ancien et attend de l’ISO-8859-1 (Latin-1).
3. Copiez le résultat avec Copier l’en-tête pour la ligne complète Authorization: Basic …, ou Copier le jeton seul pour la partie Base64.
4. Sous Code prêt à l’emploi, réglez URL sur votre endpoint et copiez l’extrait pour votre client. Inverser envoie l’en-tête au décodeur pour le vérifier.

Ce que contient l’en-tête

L’authentification Basic est définie dans la RFC 7617. Le client joint les deux valeurs avec un deux-points, encode les octets en Base64 et les envoie dans un seul en-tête :

Les deux dernières lignes montrent pourquoi le jeu de caractères compte : le même texte produit des octets différents, si bien qu’un serveur qui attend l’autre encodage voit un mauvais mot de passe. Un serveur qui veut de l’UTF-8 peut le dire dans son challenge : WWW-Authenticate: Basic realm="api", charset="UTF-8".

Le Base64 n’est ici qu’un format de transport. Quiconque copie l’en-tête peut le reconvertir en mot de passe avec le décodeur Basic Auth : c’est pourquoi Basic auth ne s’utilise qu’en HTTPS. Le Base64 n’est pas un chiffrement détaille ce point.

Les caractères qui déclenchent un avertissement

• Un deux-points dans le nom d’utilisateur. La RFC 7617 l’interdit. Le serveur coupe au premier deux-points : une partie du nom d’utilisateur se retrouverait dans le mot de passe.
• Les caractères de contrôle comme les tabulations ou les sauts de ligne, interdits dans les identifiants Basic.
• Les caractères absents de Latin-1 quand ce jeu de caractères est sélectionné, par exemple les emoji ou le cyrillique. Ils sont remplacés par ?, ce qui n’est jamais ce que vous voulez.
• Le non-ASCII en UTF-8. Correct selon la RFC, mais les anciens serveurs peuvent le lire autrement : testez d’abord.

Un deux-points dans le mot de passe est autorisé, puisque seul le premier deux-points sépare les deux valeurs.

Envoyer du Basic auth depuis le code

Les extraits de l’outil sont générés avec vos valeurs et correctement échappés pour chaque langage. Les versions simples ressemblent à ceci :

curl -u 'deploy:hunter2' https://api.example.com/

import requests

r = requests.get("https://api.example.com/",
                 auth=("deploy".encode("utf-8"), "hunter2".encode("utf-8")))

L’exemple Python passe volontairement des octets. Quand requests reçoit des valeurs str, il les encode en Latin-1 : un mot de passe contenant € ou ł échouerait. Avec des octets, il envoie exactement l’UTF-8 que vous avez choisi.

En JavaScript dans le navigateur, construisez l’en-tête vous-même : fetch refuse les URL contenant user:pass@, et btoa() lève une exception sur les caractères hors de Latin-1 ; encodez donc la chaîne en octets UTF-8 avant le Base64. L’extrait fetch généré contourne les deux problèmes en intégrant le jeton final. Le guide Base64 en JavaScript explique l’étape UTF-8, et Node.js montre la version avec Buffer.

Quand la requête renvoie toujours 401

Vérifiez d’abord l’en-tête WWW-Authenticate de la réponse. S’il indique Bearer, l’API attend un jeton et n’acceptera jamais d’identifiants Basic. S’il indique Basic, décodez l’en-tête que vous avez réellement envoyé (avec curl -v, il s’affiche sous la forme > Authorization: Basic …) et comparez-le à ce que vous attendiez ; des espaces parasites ou un saut de ligne final copiés depuis un gestionnaire de mots de passe sont des coupables fréquents. Les proxys utilisent leur propre en-tête, Proxy-Authorization, au même format.

FAQ