Générateur d'en-têtes Basic Auth
Construisez et décodez des en-têtes d'authentification HTTP Basic à partir d'un nom d'utilisateur et d'un mot de passe, entièrement dans votre navigateur.
Chargement de Générateur d'en-têtes Basic Auth… Si rien ne se passe, activez JavaScript.
L'authentification HTTP Basic est le schéma d'identifiants le plus simple défini pour le web, spécifié dans le RFC 7617. Pour s'authentifier, un client combine un nom d'utilisateur et un mot de passe en une seule chaîne séparée par deux-points, encode cette chaîne en base64 et l'envoie dans un en-tête Authorization préfixé par le mot Basic. Une requête vers un point d'accès protégé porte donc un en-tête tel que Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l. Comme le schéma est intégré à pratiquement tous les clients HTTP, bibliothèques et passerelles d'API, il reste un choix courant pour les services internes, les scripts, les webhooks et les tests rapides d'API où un flux complet basé sur des jetons serait excessif.
Questions fréquentes
Mon nom d'utilisateur et mon mot de passe sont-ils envoyés quelque part ?
Comment un en-tête Basic auth est-il construit ?
L'authentification Basic est-elle sûre ?
Que se passe-t-il si mon mot de passe contient un deux-points ?
Gère-t-il correctement les caractères non ASCII ?
Puis-je décoder un jeton que je possède déjà ?
Pourquoi le décodage échoue-t-il parfois ou n'affiche-t-il aucun deux-points ?
Comment utiliser l'en-tête généré avec curl ?
À propos de Générateur d'en-têtes Basic Auth
Ce générateur transforme un nom d'utilisateur et un mot de passe à la fois en l'en-tête Authorization complet et en le jeton base64 brut, chacun avec son propre bouton de copie afin que vous puissiez déposer la valeur directement dans curl, Postman, un appel fetch ou un fichier de configuration. Il utilise un encodeur sûr pour UTF-8, ce qui importe car le base64 simple dans le navigateur ne gère que les caractères Latin-1 par défaut. Si votre nom d'utilisateur ou votre mot de passe contient des lettres accentuées, des emoji ou tout caractère non ASCII, l'outil encode les octets correctement afin que le serveur destinataire reconstruise les identifiants exacts que vous avez saisis. La direction inverse est également prise en charge : collez un jeton base64 ou un en-tête Authorization complet et l'outil le redécoupe en le nom d'utilisateur et le mot de passe qu'il représente.
Tout se passe localement dans votre navigateur. Les identifiants que vous saisissez ne sont jamais téléversés, transmis ni stockés sur un serveur, ce qui rend l'outil sûr pour de vrais noms d'utilisateur et mots de passe pendant le développement et le débogage. Cela dit, l'authentification Basic n'offre aucune confidentialité par elle-même. L'étape base64 est réversible par n'importe qui, c'est donc de l'encodage, pas du chiffrement. Basic auth ne devrait jamais être envoyée que sur HTTPS, où TLS protège l'en-tête en transit. Utilisez cet outil pour construire des en-têtes de test et pour inspecter les jetons que vous avez reçus, et conservez les identifiants de production dans un véritable coffre à secrets plutôt que codés en dur dans les scripts.
Le plus ancien schéma d'authentification encore présent sur le web
L'authentification HTTP Basic remonte à la spécification originale de HTTP/1.0 en 1996 et a survécu pratiquement inchangée depuis. Son mécanisme est presque comiquement simple : prenez un nom d'utilisateur et un mot de passe, collez-les ensemble avec un deux-points, encodez le résultat en base64 et envoyez-le. Il n'y a ni hachage, ni nonce, ni échange défi-réponse du genre que l'on trouve dans l'authentification Digest. L'étape base64 existe uniquement pour rendre des octets d'identifiants arbitraires sûrs à placer dans un en-tête HTTP, pas pour cacher quoi que ce soit.
Cette simplicité est exactement la raison pour laquelle elle reste partout. Presque toutes les bibliothèques HTTP exposent un assistant d'une ligne pour elle, les passerelles d'API et les proxys inverses la prennent en charge nativement, et les développeurs peuvent construire l'en-tête à la main lors du débogage. Les microservices internes, les points de surveillance, les registres de paquets et d'innombrables systèmes hérités s'appuient encore sur elle parce qu'elle est universellement comprise et ne nécessite aucune infrastructure supplémentaire. Le hic, c'est que les identifiants voyagent à chaque requête, de sorte que la sécurité de tout le schéma repose entièrement sur la couche de transport sous-jacente.
Les célèbres identifiants d'exemple aladdin et opensesame, qui apparaissent dans le RFC 7617 et dans de nombreux tutoriels, sont un clin d'oeil au conte d'Ali Baba et les quarante voleurs, où opensesame (sésame, ouvre-toi) est la phrase magique qui ouvre la caverne cachée. C'est une métaphore appropriée pour un schéma d'authentification : prononcez le bon secret et la porte s'ouvre. La leçon que le conte et le schéma partagent est la même : un secret prononcé ou transmis n'est jamais plus sûr que les oreilles qui pourraient être à l'écoute, ce qui explique pourquoi Basic auth a strictement sa place à l'intérieur d'un tunnel HTTPS.