Chaque développeur ayant intégré une API tierce a heurté le même mur : les documents disent " ; s'authentifier avec Basic auth," ; vous collez votre clé et votre secret dans une requête, et le serveur répond avec un plat 401 Unauthorized et aucune indication sur pourquoi Neuf fois sur dix, l'identifiant a été codé légèrement mal, et il n'y a rien dans l'erreur pour vous dire que J'ai construit et consommé suffisamment d'API sur les plugins WordPress et les backends de Laravel pour avoir perdu une quantité embarrassante de temps exactement sur ceci, alors j'ai mis un générateur d'authentification de base sur Toolz.dev cela construit l'en-tête correctement à chaque fois et en décode un lorsque vous devez vérifier. C'est le guide et le schéma qui le sous-tend.
tl;dr : HTTP Basic Authentication envoie un nom d'utilisateur et un mot de passe comme
base64(username:password)dans leAuthorizationen-tête. Le Toolz générateur d'authentification de base transforme un nom d'utilisateur et un mot de passe en en-tête exact, une commande curl prête à l'emploi, un extrait de récupération et le formulaire d'informations utilisateur de l'URL, et décode les jetons existants. Il code sur UTF-8 afin que les informations d'identification non ASCII survivent, avertit lorsque le nom d'utilisateur contient deux points et s'exécute entièrement côté client.
Qu'est-ce que l'authentification de base HTTP ?
HTTP Basic Authentication est le schéma d'informations d'identification le plus simple défini par le Web. Il est spécifié dans RFC7617(, qui se trouve au-dessus du cadre général d'authentification HTTP dans RFC7235. L'idée est minime : pour prouver qui vous êtes, vous envoyez un Authorization en-tête dont la valeur est le mot Basic1, un espace, puis l'encodage base64 de votre nom d'utilisateur et de votre mot de passe rejoint par deux points.
Concrètement, si votre nom d'utilisateur est admin et votre mot de passe est secret, le client forme la chaîne admin:secret, l'encode comme UTF-8 octets, base64-encode ces octets à obtenir YWRtaW46c2VjcmV0et envoie:
Authorization: Basic YWRtaW46c2VjcmV0
C'est tout le schéma Il n'y a pas de poignée de main, pas de nonce, pas de hachage Sa simplicité est exactement la raison pour laquelle il a survécu : il est trivial à implémenter aux deux extrémités, et pour les outils internes, les registres privés, les webhooks, et d'innombrables API c'est toujours la valeur par défaut Le catch, et c'est un gros, c'est que l'encodage est complètement réversible, ce qui façonne tout sur la façon dont vous devriez l'utiliser.
L'encodage base64 est-il identique à celui du chiffrement ?
Non, et c'est la chose la plus importante à comprendre à propos de l'authentification de base. Base64, défini dans RFC 4648(en anglais), est un codage de transport Son but est de représenter des données binaires ou textuelles en utilisant un ensemble sûr de 64 caractères imprimables afin qu'il survive à l'envoi par des systèmes qui attendent du texte Ce n'est pas un chiffrement, il n'utilise aucune clé, et l'inverser fait un pas N'importe qui qui peut voir YWRtaW46c2VjcmV0 peut le décoder à nouveau admin:secret instantanément, c'est ce que fait cet outil et le mode de décodage n°39 ; s.
La conséquence est que l'authentification de base offre une confidentialité nulle à elle seule. L'identifiant est effectivement envoyé en clair, portant simplement un mince déguisement. C'est pourquoi la seule règle non négociable de l'authentification de base est qu'il ne doit voyager que via HTTPS. TLS crypte toute la requête, y compris la Authorization header, donc l'identifiant base64 est protégé en transit Envoyez l'authentification de base via HTTP simple et vous avez publié votre mot de passe à toute personne sur le chemin réseau.
Je travaille sur ce point parce que l'étape base64 trompe les gens en leur faisant croire que l'identifiant est brouillé d'une manière significative. Ce n’est pas le cas. Traitez le jeton base64 avec le même soin que vous traiteriez le mot de passe brut, car ils sont trivialement interconvertibles. Le outils en ligne de confidentialité des données le guide explique pourquoi cet outil effectue l'encodage dans votre navigateur plutôt que sur un serveur, ce qui est tout l'intérêt d'un identifiant en direct.
Comment l'en-tête d'authentification Basic est-il construit, étape par étape ?
La construction est composée de quatre petites étapes, et se tromper légèrement produit un titre qui échoue silencieusement :
- Rejoignez-nous avec deux points. Formez la chaîne
username:password. Le deux-points est le délimiteur. - Encoder comme UTF-8. Transformez cette chaîne en octets à l'aide d'UTF-8. cela compte pour tout caractère non ASCII.
- Base64-encoder les octets. Appliquer la base standard64 pour produire le jeton.
- Préfixe avec
Basic. La valeur finale de l'en-tête estBasicsuivi du jeton.
le générateur fait les quatre et vous remet l'en-tête fini Il produit également les formulaires que vous collez réellement dans un terminal ou une base de code : une commande curl utilisant le -u flag, une commande curl avec l'explicite -H 'Authorization: Basic ...' en-tête, extrait de récupération, jeton nu seul et formulaire d'informations utilisateur d'URL https://user:pass@host. Différentes tâches veulent différentes formes, et retaper la base64 à la main est précisément l'endroit où les erreurs s'insinuent.
Pourquoi le nom d'utilisateur compte-t-il plus que le mot de passe ?
Il y a une asymétrie dans le schéma qui fait constamment trébucher les gens, et elle vient directement de la première étape. Le titre est partagé sur le premier deux points. Cela signifie que le nom d'utilisateur ne peut pas contenir deux points, car le serveur lirait les premiers deux points de votre nom d'utilisateur comme limite et remettrait le reste au champ du mot de passe. Le mot de passe, en revanche, peut contenir autant de deux points qu'il le souhaite, puisque tout après les premiers deux points est le mot de passe.
La RFC 7617 l'indique directement : l'identifiant utilisateur ne doit pas contenir de deux points. C'est facile à violer sans s'en apercevoir, surtout lorsque le nom d'utilisateur est lui-même quelque chose de structuré comme une clé API ou un identifiant en forme d'e-mail qui se trouve inclure un deux-points Le générateur surveille exactement cela et vous avertit lorsque le nom d'utilisateur contient deux-points, car l'identifiant résultant décodera avec la division au mauvais endroit et produira un 401 qui ne vous donne aucun indice sur la cause.
Voici la règle dans un tableau, car cela vaut la peine d'être sans ambiguïté.
| champ de courses | Peut contenir un côlon ? | Raison |
|---|---|---|
| nom d'utilisateur | non | Le premier deux-points est le délimiteur |
| mot de passe | oui | Tout ce qui se trouve après les premiers deux points est le mot de passe |
J'ai débogué cet échec exact dans la nature, où un service a émis API " ; noms d'utilisateur" ; qui contenait occasionnellement deux points et l'intégration fonctionnait pour la plupart des clients et échouait mystérieusement pour quelques-uns. L'avertissement tool' ;s aurait été enregistré cet après-midi-là.
Pourquoi l'encodage UTF-8 est-il important ?
Pour un nom d'utilisateur et un mot de passe entièrement ASCII, l'étape d'encodage est invisible ; chaque caractère est d'un octet et base64 fait son truc Au moment où un identifiant contient une lettre accentuée, un script non latin, ou un emoji, l'encodage des octets devient décisif La RFC 7617 recommande UTF-8 précisément pour que client et serveur s'accordent sur les octets de ces caractères.
Un encodeur naïf qui suppose qu'un caractère est un octet ou qui s'appuie sur une API de navigateur avec un comportement hérité se corrompra café ou пароль dans les mauvais octets, et le jeton de base64 qu'il produit ne correspondra pas à ce qu'un serveur conforme a calculé à partir du même identifiant Le résultat est un autre silencieux 401. ce générateur code manuellement l'identifiant sur UTF-8, donc un mot de passe comme café:naïve produit exactement les octets qu'un client RFC 7617 enverrait, et le côté décodage l'inverse fidèlement Si vous avez déjà EU un identifiant qui a fonctionné pour un coéquipier et pas un autre, un caractère non-ASCII codé de manière incohérente est un suspect principal.
Comment décoder un jeton d'authentification Basic ?
Parce que l'encodage est réversible, vérifier un identifiant est aussi simple que d'en produire un Prenez la partie après Basic (en), base64-décodez-le, lisez le résultat comme UTF-8 et divisez-le sur les premiers deux points. Le générateur's le mode Décode fait ceci : collez un full Authorization: Basic ... ligne, un nu Basic ... valeur, ou simplement le jeton, et il vous montre le nom d'utilisateur et le mot de passe qu'il transporte.
C'est vraiment utile, pas seulement une curiosité Lorsqu'on vous remet un identifiant de travail et qu'on vous demande de le reproduire dans un nouvel environnement, le décodage vous indique exactement quel nom d'utilisateur et mot de passe il code afin que vous puissiez les définir correctement Lorsqu'une intégration échoue, décoder le jeton que vous envoyez réellement et le comparer à ce que vous aviez prévu est souvent le moyen le plus rapide de repérer un espace parasite, un mauvais champ ou deux points au mauvais endroit Et c'est un rappel éclatant du point de confidentialité ci-dessus : si vous pouvez le décoder facilement, ainsi peut quiconque l'intercepte via un HTTP simple.
Où le générateur s'adapte aux autres outils
L'authentification de base est l'un des nombreux outils d'identification et de demande sur le site qui partagent le même modèle de téléchargement sans téléchargement côté client. Lorsque le jeton que vous inspectez est un jeton porteur plutôt qu'un authentification de base, le Décodeur JWT lit les réclamations à partir d'un JSON Web Token Lorsque vous avez besoin d'un hachage plutôt que d'un encodage, pour une somme de contrôle ou un résumé de mot de passe, le générateur de hachage le calcule. Lorsque vous souhaitez simplement coder ou décoder arbitraire base64 plutôt qu'un identifiant en particulier, le convertisseur base64 gère le cas général Et lorsque vous déboguez la requête elle-même et que vous voulez savoir quel client l'a envoyée, le analyseur d'agent utilisateur lit l'en-tête User-Agent.
Pour une carte plus large de la manière dont ces utilitaires de demande et de réponse fonctionnent ensemble, le Boîte à outils pour les développeurs Web roundup parcourt une session de débogage réaliste, et le Outils de productivité des développeurs guide couvre l'assemblage d'un ensemble personnel d'entre eux L'authentification de base apparaît rarement isolément ; il s'agit généralement d'une ligne dans une demande que vous essayez de faire fonctionner.
Un exemple concret : câbler une intégration d’API
Laissez-moi ancrer cela dans la tâche que j'ai le plus touchée Vous intégrez un service tiers dont les docs disent de s'authentifier avec Basic auth en utilisant une clé API comme nom d'utilisateur et un mot de passe vide, ou une paire clé et secret Les docs vous donnent les identifiants mais pas l'en-tête, et la première requête échoue.
Le chemin fiable consiste à construire l'en-tête explicitement et à le tester avec curl avant d'écrire une ligne de code d'application Collez la clé et le secret dans le générateur[TRADUCTION], copiez le curl -H formez-le et exécutez-le contre un point de terminaison connu. Si la boucle réussit et que votre code ne réussit pas, le problème se trouve dans votre code' ; la construction de la requête, pas l'identifiant, et vous venez de couper l'espace de recherche de moitié. Si la boucle échoue également, l'identifiant lui-même est faux et le décodage du jeton confirme exactement quel champ est désactivé.
Dans un plugin WordPress, j'ai souvent besoin d'appeler une API externe depuis PHP, et la valeur d'en-tête correcte est ce que j'alimente wp_remote_get via le Authorization argument d'en-tête. Dans Laravel, cela entre dans le withHeaders faites appel au client HTTP, ou j'utilise le framework' ; s withBasicAuth helper, qui construit le même en-tête pour moi De toute façon, avoir la valeur d'en-tête connue-bonne du générateur signifie que je débogue mon code de demande contre un identifiant que j'ai déjà prouvé fonctionne, plutôt que de déboguer les deux à la fois Le cas du mot de passe vide est celui où le générateur gagne sa garde, car il est facile d'oublier cela key: avec un deux-points final, il existe un identifiant différent, et souvent correct key seul.
La dernière discipline est celle de la sécurité Ne collez pas l'en-tête résultant dans un document partagé, un ticket ou un chat, et n'envoyez pas d'authentification de base sur autre chose que HTTPS. Le jeton est le mot de passe. Parce que cet outil code dans votre navigateur et ne télécharge jamais rien, générer l'identifiant est sûr ; où il va ensuite est sur vous.
Quand dois-je utiliser Basic auth, et quand ne devrais-je pas ?
L'authentification de base n'est pas l'outil adapté à chaque travail, et savoir où elle s'adapte vous évite des ennuis Sa force est la simplicité : pour les appels de serveur à serveur, les outils internes, les registres de paquets privés, les travaux CI et les webhooks où les deux extrémités se font déjà confiance et où tout tourne sur HTTPS, il est difficile de battre Il n'y a rien à négocier, aucun jeton à rafraîchir, et chaque client HTTP et bibliothèque le prend en charge hors de la boîte Lorsque vous contrôlez les deux côtés et que la connexion est cryptée, l'authentification de base est un choix parfaitement raisonnable qui a continué à fonctionner pendant trente ans.
Ses faiblesses apparaissent au moment où vous sortez de cette case Parce que l'identifiant est envoyé sur chaque requête, une seule ligne de journal divulguée ou un proxy qui enregistre les en-têtes l'expose de manière permanente, et le faire tourner signifie le changer partout à la fois Il n'a pas de concept de portée, donc un identifiant de base est tout ou rien : il ne peut pas accorder un accès en lecture seule ou expirer après une heure Et il met un mot de passe réel et de longue durée sur le fil à chaque appel, alors que les schémas basés sur des jetons vous permettent de distribuer un identifiant de courte durée et étroitement scopé à la place.
Pour l'authentification orientée utilisateur, ou partout où vous avez besoin de portées, d'expiration ou de révocation, un jeton support est le meilleur modèle, et le Décodeur JWT est l'outil compagnon pour inspecter ceux-ci Une règle empirique utile : atteindre pour l'authentification de base pour les appels machine à machine que vous contrôlez entièrement, et atteindre pour les jetons lorsqu'un tiers, une session de navigateur, ou une limite d'autorisation est impliqué Le tableau ci-dessous résume le commerce.
| Utilisez l'authentification de base pour | Préférez les jetons pour |
|---|---|
| L'API serveur à serveur vous appelle à contrôler | Séances destinées aux utilisateurs |
| Outils internes et registres privés | Accès à portée ou en lecture seule |
| tâches et webhooks CI via HTTPS | Pouvoirs qui doivent expirer |
Questions fréquentes
Qu'est-ce que l'authentification de base HTTP ? HTTP Basic Authentication est un schéma dans lequel un client envoie un nom d'utilisateur et un mot de passe avec chaque requête dans l'en-tête Authorization La valeur est le mot Basic suivi de l'encodage base64 du nom d'utilisateur : mot de passe Il est défini dans la RFC 7617 et constitue le moyen le plus simple pour un serveur de vérifier les informations d'identification.
Comment l'en-tête d'authentification Basic est-il construit ? Rejoignez le nom d'utilisateur et le mot de passe avec un seul deux points pour former le nom d'utilisateur : mot de passe, coder cette chaîne en tant qu'octets UTF-8, coder les octets en base64 et préfixer le résultat avec Basic. L'en-tête final est Autorisation : Basic suivi de ce jeton.
L'authentification de base est-elle sécurisée ? Uniquement via HTTPS. Base64 encode, pas cryptage, donc toute personne capable de lire l'en-tête peut décoder le mot de passe instantanément. L'authentification de base n'offre aucune confidentialité en soi et doit toujours être envoyée via une connexion TLS pour être sûre.
Le nom d'utilisateur peut-il contenir deux points ? Non. Le premier deux points sépare le nom d'utilisateur du mot de passe, donc deux points dans le nom d'utilisateur seraient mal lus comme limite et diviserait l'identifiant au mauvais endroit. Le mot de passe peut contenir n'importe quel nombre de deux points. Le générateur vous avertit si le nom d'utilisateur en possède un.
Comment décoder un jeton d'authentification Basic ? Prenez la partie base64 après Basic, décodez-la en base64 et lisez-la comme texte UTF-8. le résultat est nom d'utilisateur : mot de passe, divisé sur les premiers deux points Collez n'importe quel en-tête d'authentification Basic dans le mode de décodage tool' ; s pour le faire instantanément.
Quel est l'équivalent de la boucle ? curl - u nom d'utilisateur : mot de passe https://exemple.com fait la même chose, car curl construit l'en-tête Authorization : Basic pour vous à partir de la valeur - u. L'outil affiche à la fois ce formulaire et le formulaire d'en-tête - H explicite afin que vous puissiez copier celui qui convient.
Cet outil envoie-t-il mes informations d'identification n'importe où ? Non. L'encodage et le décodage s'exécutent entièrement dans votre navigateur avec JavaScript. Votre nom d'utilisateur et votre mot de passe ne sont jamais téléchargés sur aucun serveur, il est donc sûr de les utiliser avec des informations d'identification réelles et en direct.
Pourquoi utiliser l'encodage UTF-8 pour l'identifiant ? La RFC 7617 recommande UTF-8 afin que les noms d'utilisateur et mots de passe non ASCII codent de manière cohérente entre le client et le serveur. Un encodeur qui suppose que l'ASCII corromprait les lettres accentuées ou les scripts non latins, produisant un jeton que le serveur ne peut pas correspondre.
