Générez un en-tête d'authentification HTTP Basic à partir d'un nom d'utilisateur et d'un mot de passe, obtenez une commande curl prête à coller, et décodez un jeton Basic existant en identifiants.
Créez un en-tête d'authentification HTTP Basic, ou décodez-en un. Saisissez un nom d'utilisateur et un mot de passe pour obtenir l'en-tête Authorization, le jeton base64 brut et une commande curl à coller directement dans un terminal. Le décodeur ci-dessous inverse un jeton existant.
Décoder un jeton existant
Tout est calculé dans votre navigateur et rien n'est transmis. Même ainsi, évitez de coller des identifiants de production dans une page web, y compris celle-ci.
L'authentification Basic, définie dans la RFC 7617, est le schéma le plus simple de HTTP. Le client joint le nom d'utilisateur et le mot de passe avec un deux-points, encode le résultat en base64, et l'envoie dans un en-tête :
Authorization: Basic YWxpY2U6czNjcjN0
Lorsqu'un serveur demande des identifiants, il répond 401 Unauthorized avec un en-tête WWW-Authenticate: Basic realm="...", et le navigateur affiche sa fenêtre de connexion native. Il n'y a pas de poignée de main, pas de nonce et pas d'expiration — chaque requête transporte le même en-tête.
Base64 n'est pas un chiffrement
C'est le point que tout le monde doit intérioriser. Base64 est un encodage de transport réversible sans clé ni secret. Toute personne voyant l'en-tête peut le décoder instantanément, ce que fait exactement le décodeur de cette page. Basic auth n'offre donc aucune confidentialité en soi et ne doit être utilisée que sur HTTPS, où TLS protège toute la requête. En HTTP simple, c'est équivalent à envoyer le mot de passe en clair.
La règle des deux-points
Le nom d'utilisateur ne peut pas contenir de deux-points, car le premier deux-points est le séparateur. Le mot de passe peut en contenir autant que souhaité — un décodeur découpe sur le premier et traite le reste comme le mot de passe. Si votre nom d'utilisateur a vraiment besoin d'un deux-points, Basic auth n'est pas utilisable et il vous faut un autre schéma.
Encodage des caractères
La spécification d'origine était vague sur tout ce qui dépasse l'ASCII, ce qui causait historiquement des ruptures des mots de passe non ASCII entre clients et serveurs. La RFC 7617 a ajouté le paramètre charset="UTF-8" pour qu'un serveur puisse exprimer son attente, et en pratique chaque pile moderne utilise l'UTF-8. Cet outil encode en octets UTF-8 avant le base64, conformément au comportement actuel des navigateurs.
Où cela reste pertinent
Basic auth reste un choix raisonnable pour les appels machine-à-machine sur des réseaux internes, pour une protection rapide d'un environnement de préproduction derrière nginx ou Apache, pour des tâches CI nécessitant un identifiant simple, et comme transport de clés API où la clé va dans le champ nom d'utilisateur et le mot de passe reste vide ou défini à un placeholder comme x. Plusieurs API de paiement et de messagerie utilisent exactement ce modèle.
C'est un mauvais choix pour la connexion des utilisateurs finaux sur un site public. Il n'y a pas de déconnexion, le navigateur met en cache les identifiants pour la session, la fenêtre ne peut pas être stylée, et il est impossible d'ajouter une authentification multifacteur ou une limitation de débit par session. Utilisez plutôt un schéma par jeton ou par session.
Précautions pratiques
Les identifiants intégrés dans une URL — user:pass@example.com — sont obsolètes et bloqués ou supprimés par la plupart des navigateurs, car ils fuitent dans l'historique, les journaux et les en-têtes de référent. Passer -u user:pass à curl enregistre aussi le mot de passe dans l'historique de votre shell et dans la liste des processus, où d'autres utilisateurs de la machine peuvent le voir ; préférez -u user et laissez curl demander, ou lisez la valeur depuis une variable d'environnement.
FAQ
Basic auth est-il sécurisé ?
Uniquement sur HTTPS. L'encodage base64 n'offre aucune protection — il est trivialement réversible. Avec TLS, les identifiants sont protégés en transit comme toute autre donnée de requête ; sans TLS, ils sont effectivement en clair.
Pourquoi du base64 s'il ne s'agit pas d'un chiffrement ?
Son but est la sûreté de transport, pas le secret. Base64 garantit que l'identifiant ne contient que des caractères ASCII sûrs pour l'en-tête, si bien qu'un deux-points, une espace ou un octet non ASCII dans le mot de passe ne peut pas corrompre l'en-tête.
Le nom d'utilisateur peut-il contenir un deux-points ?
Non. Le premier deux-points sépare le nom d'utilisateur du mot de passe, donc un deux-points dans le nom d'utilisateur rend l'identifiant ambigu. Les mots de passe peuvent contenir autant de deux-points que souhaité.
Comment me déconnecter de Basic auth ?
Il n'y a pas de mécanisme propre. Les navigateurs mettent en cache les identifiants pour la session, et les contournements habituels consistent à fermer le navigateur ou à renvoyer un 401 vers un point de terminaison spécial. Cette limitation est une raison pour laquelle Basic auth ne convient pas à la connexion des utilisateurs finaux.
Le jeton expire-t-il ?
Jamais. Le même en-tête est valide jusqu'au changement du mot de passe, ce qui fait qu'un jeton Basic fuité est aussi grave qu'un mot de passe fuité. Rotez les identifiants s'il en est jamais exposé.
Mes identifiants sont-ils envoyés quelque part ?
Non. L'encodage et le décodage s'exécutent entièrement dans votre navigateur. Cela dit, il est bon de ne jamais coller de vrais identifiants de production dans une page web.