Elke ontwikkelaar die een API van derden heeft geïntegreerd, heeft dezelfde muur geraakt: de documenten zeggen " authenticeren met Basic auth, & quot; u plakt uw sleutel en geheim in een verzoek en de server antwoordt met een flat 401 Unauthorized en geen hint over waarom Negen van de tien keer was de inloggegevens enigszins verkeerd gecodeerd, en er zit niets in de fout om je dat te vertellen. Ik heb genoeg API's gebouwd en geconsumeerd in WordPress-plug-ins en Laravel-backends om precies hieraan een beschamende hoeveelheid tijd te hebben verspild, dus heb ik er een basisauth generator in Toolz.dev dat bouwt de header elke keer correct op en decodeert er één terug wanneer je moet controleren Dit is de gids voor het en voor het schema erachter.
tl;dr: HTTP Basic Authentication verzendt een gebruikersnaam en wachtwoord als
base64(username:password)in deAuthorizationkoptekst. De Toolz basisauth generator verandert een gebruikersnaam en wachtwoord in de exacte header, een kant-en-klaar curl-commando, een ophaalfragment en het URL-gebruikersinfovorm, en decodeert bestaande tokens terug. Het codeert via UTF-8 zodat niet-ASCII-referenties overleven, waarschuwt wanneer de gebruikersnaam een dubbele punt bevat en volledig aan de clientzijde draait.
Wat is HTTP Basic Authentication?
HTTP Basic Authentication is het eenvoudigste inlogschema dat het web definieert. Het wordt gespecificeerd in RFC-7617, dat bovenop het algemene HTTP-authenticatieframework zit RFC-7235. Het idee is minimaal: om te bewijzen wie je bent, stuur je een Authorization header waarvan de waarde het woord is Basic, een spatie en vervolgens de basis64-codering van uw gebruikersnaam en wachtwoord, verbonden door een enkele dubbele punt.
Concreet, als uw gebruikersnaam dat is admin en je wachtwoord is secret, de client vormt de string admin:secret, codeert het als UTF-8 bytes, base64 codeert die bytes om te verkrijgen YWRtaW46c2VjcmV0, en verzendt:
Authorization: Basic YWRtaW46c2VjcmV0
Dat is het hele schema Er is geen handdruk, geen nonce, geen hashing De eenvoud is precies waarom het is overleefd: het is triviaal om te implementeren aan beide kanten, en voor interne tools, privéregisters, webhooks en talloze API's is het nog steeds de standaard. De vangst, en het is een grote, is dat de codering volledig omkeerbaar is, wat alles bepaalt over hoe je het moet gebruiken.
Is base64-codering hetzelfde als encryptie?
Nee, en dit is het allerbelangrijkste om te begrijpen over Basic auth. Base64, gedefinieerd in RFC 4648, is een transportcodering Het doel ervan is om binaire of tekstgegevens weer te geven met behulp van een veilige set van 64 afdrukbare tekens, zodat het overleeft dat het wordt verzonden via systemen die tekst verwachten Het is geen cijfer, het gebruikt geen sleutel, en het omkeren ervan neemt één stap Iedereen die kan zien YWRtaW46c2VjcmV0 kan het terug decoderen naar admin:secret direct, wat deze tool's decodeermodus doet.
Het gevolg is dat Basic authenticatie op zichzelf nul vertrouwelijkheid biedt De credential wordt effectief in de duidelijke verzonden, alleen maar met een dunne vermomming. Dit is de reden waarom de enige niet-onderhandelbare regel van Basic auth is dat het alleen over HTTPS mag reizen. TLS codeert het hele verzoek, inclusief de Authorization header, dus de basis64-referentie is onderweg beveiligd Verstuur Basic auth via gewone HTTP en u hebt uw wachtwoord gepubliceerd aan iedereen op het netwerkpad.
Ik werk dit punt uit omdat de basis64-stap mensen voor de gek houdt door te denken dat de inloggegevens op een zinvolle manier zijn gecodeerd. Dat is niet zo. Behandel het basis64-token met dezelfde zorg als het ruwe wachtwoord, omdat ze triviaal interconverteerbaar zijn. De online tools voor gegevensprivacy de gids behandelt waarom deze tool de codering in uw browser uitvoert in plaats van op een server, wat voor een live-inloggegevens het hele punt is.
Hoe wordt de Basic auth header stap voor stap gebouwd?
De constructie bestaat uit vier kleine stappen, en als je een van deze stappen enigszins verkeerd doet, ontstaat er een legitimatie die stilletjes faalt:
- Sluit je aan met een dubbele punt. Vorm de string
username:password. De dikke darm is de scheidingsteken. - Coderen als UTF-8. Verander die string in bytes met behulp van UTF-8 Dit is belangrijk voor elk niet-ASCII-teken.
- Base64-codeer de bytes. Pas standaardbasis64 toe om het token te produceren.
- Voorvoegsel met
Basic. De uiteindelijke headerwaarde isBasicgevolgd door het token.
de generator doet ze alle vier en overhandigt u de voltooide header Het produceert ook de formulieren die u daadwerkelijk in een terminal of een codebase plakt: een krulopdracht met behulp van de -u vlag, een krulcommando met de expliciete -H 'Authorization: Basic ...' header, een ophaalfragment, het kale token op zichzelf en het URL-gebruikersinfovorm https://user:pass@host. Verschillende taken willen verschillende vormen, en het met de hand overtypen van de basis64 is precies waar fouten insluipen.
Waarom doet de gebruikersnaam er meer toe dan het wachtwoord?
Er is één asymmetrie in het schema die mensen voortdurend naar boven laat struikelen, en deze komt rechtstreeks uit stap één. De inloggegevens zijn verdeeld over de liever dubbele punt. Dat betekent dat de gebruikersnaam geen dubbele punt kan bevatten, omdat de server de eerste dubbele punt in uw gebruikersnaam als grens zou lezen en de rest ervan aan het wachtwoordveld zou overhandigen. Het wachtwoord kan daarentegen zoveel dubbele punten bevatten als het wil, aangezien alles na de eerste dubbele punt het wachtwoord is.
RFC 7617 vermeldt dit direct: de user-id mag geen dubbele punt bevatten Dit is gemakkelijk te schenden zonder het te merken, vooral wanneer de gebruikersnaam zelf iets is dat is gestructureerd zoals een API-sleutel of een e-mailvormige identificatie die toevallig een dubbele punt bevat De generator kijkt hier precies naar en waarschuwt u wanneer de gebruikersnaam een dubbele punt bevat, omdat de resulterende inloggegevens met de splitsing op de verkeerde plaats decoderen en een 401 produceren die u geen idee geeft van de oorzaak.
Hier is de regel in een tabel, omdat het de moeite waard is om ondubbelzinnig te zijn.
| veld | Kan een dikke darm bevatten? | Reden |
|---|---|---|
| gebruikersnaam | heel weinig | De eerste dubbele punt is de scheidingsteken |
| consigne | ja | Alles na de eerste dubbele punt is het wachtwoord |
Ik heb deze exacte storing in het wild debuggen, waar een dienst API & quot; gebruikersnamen" dat af en toe een dubbele punt bevatte en de integratie werkte voor de meeste klanten en voor een paar op mysterieuze wijze mislukte De tool' s waarschuwing zou die middag hebben opgeslagen.
Waarom is UTF-8-codering belangrijk?
Voor een all-ASCII gebruikersnaam en wachtwoord is de coderingsstap onzichtbaar; elk teken is één byte en base64 doet zijn ding Op het moment dat een credential een letter met accenten, een niet-Latijns script of een emoji bevat, wordt de bytecodering doorslaggevend RFC 7617 beveelt UTF-8 juist aan zodat client en server het eens worden over de bytes voor deze tekens.
Een naïeve encoder die ervan uitgaat dat één teken één byte is, of die op een browser-API leunt met ouderwets gedrag, zal corrumperen café of пароль in de verkeerde bytes, en het basis64-token dat het produceert, komt niet overeen met wat een conforme server berekent met dezelfde inloggegevens. Het resultaat is nog een stille 401. Deze generator codeert de inloggegevens over UTF-8 met de hand, dus een wachtwoord zoals café:naïve produceert precies de bytes die een RFC 7617 client zou versturen, en de decodeerzijde draait deze getrouw om Als je ooit een credential hebt gehad die voor de ene teamgenoot werkte en niet voor de andere, is een niet-ASCII teken dat inconsistent gecodeerd is een hoofdverdachte.
Hoe decodeer ik een Basic auth-token?
Omdat de codering omkeerbaar is, is het controleren van een inloggegevens net zo eenvoudig als het produceren ervan. Neem het onderdeel daarna Basic , base64-decodeer het, lees het resultaat als UTF-8 en splits op de eerste dubbele punt. De generator's de decodeermodus doet dit: plak een volledige Authorization: Basic ... lijn, een kale Basic ... waarde, of alleen het token, en het toont u de gebruikersnaam en het wachtwoord dat het draagt.
Dit is echt handig, niet alleen een curiositeit Wanneer u een werkende credential krijgt overhandigd en wordt gevraagd om deze in een nieuwe omgeving te reproduceren, vertelt decodering u precies welke gebruikersnaam en wachtwoord het codeert, zodat u ze correct kunt instellen Wanneer een integratie mislukt, decodeert u het token dat u daadwerkelijk verzendt en vergelijkt het met wat u bedoelde, is vaak de snelste manier om een verdwaalde ruimte, een verkeerd veld of een dubbele punt op de verkeerde plaats te spotten. En het is een levendige herinnering aan het bovenstaande vertrouwelijkheidspunt: als u het zo gemakkelijk kunt decoderen, kan iedereen die het via gewone HTTP onderschept dat ook doen.
Waar de generator past bij de andere gereedschappen
Basic auth is een van de vele inloggegevens en verzoekhulpmiddelen op de site die hetzelfde client-side, no-upload-model delen Wanneer het token dat u inspecteert een dragertoken is in plaats van Basic auth, zal de JWT decoder leest de claims uit een JSON Web Token Wanneer u een hash nodig heeft in plaats van een codering, voor een controlesom of een wachtwoordoverzicht, kan de hash generator berekent het. Wanneer u alleen maar willekeurige basis64 wilt coderen of decoderen in plaats van specifiek een referentie, zal de basis64 converter behandelt de algemene zaak En wanneer u het verzoek zelf debugt en wilt weten welke client het heeft verzonden, zal de user agent parser leest de User-Agent header.
Voor een bredere kaart van hoe deze request-and-response-hulpprogramma's samenwerken, is de Webontwikkelaar Toolkit roundup loopt door een realistische foutopsporingssessie, en de Productiviteitstools voor ontwikkelaar gids behandelt het samenstellen van een persoonlijke set van hen Basic auth komt zelden op zichzelf; het is meestal één regel in een verzoek dat u probeert om werk te maken.
Een uitgewerkt voorbeeld: een API-integratie aansluiten
Laat me dit ondergronden in de taak die ik het meest tref Je integreert een service van derden waarvan de documenten zeggen dat deze zich moet authenticeren met Basic auth met behulp van een API-sleutel als gebruikersnaam en een leeg wachtwoord, of een sleutel en een geheim paar De documenten geven je de inloggegevens, maar niet de header, en het eerste verzoek mislukt.
Het betrouwbare pad is om de header expliciet te bouwen en te testen met krul voordat u een regel applicatiecode schrijft Plak de sleutel en het geheim in de generator, kopieer de curl -H vorm, en voer het uit tegen een bekend eindpunt Als krul slaagt en je code niet, zit het probleem in je code' s request construction, not the credential, en je hebt net de zoekruimte doormidden gesneden Als krul ook faalt, is de credential zelf fout, en het decoderen van het token bevestigt precies welk veld uit staat.
In een WordPress plugin moet ik vaak een externe API aanroepen van PHP, en de juiste headerwaarde is waar ik aan invoegt wp_remote_get via de Authorization header argument In Laravel gaat het in de withHeaders doe een beroep op de HTTP-client, of ik gebruik het framework's withBasicAuth helper, die voor mij dezelfde header bouwt Hoe dan ook, het hebben van de bekende goede headerwaarde van de generator betekent dat ik mijn verzoekcode debug met een inloggegevens waarvan ik al heb bewezen dat ze werken, in plaats van beide tegelijk te debuggen. In het lege wachtwoordgeval verdient de generator zijn geld, omdat je dat gemakkelijk vergeet key: bij een achterste dikke darm is er een andere, en vaak correcte, legitimatie van key alone.
De laatste discipline is de beveiligingsdiscipline Plak de resulterende header niet in een gedeeld document, een ticket of een chat en stuur Basic auth niet over iets anders dan HTTPS. Het token is het wachtwoord. Omdat deze tool in uw browser codeert en nooit iets uploadt, is het genereren van de inloggegevens veilig; waar het daarna naartoe gaat, is voor jou.
Wanneer moet ik Basic auth gebruiken, en wanneer niet?
Basic auth is niet het juiste hulpmiddel voor elke klus, en weten waar het past houdt je uit de problemen De kracht ervan is eenvoud: voor server-to-server oproepen, interne tools, privé pakketregisters, CI jobs, en webhooks waarbij de twee uiteinden elkaar al vertrouwen en alles over HTTPS loopt, is het moeilijk te verslaan Er valt niets te onderhandelen, geen token om te vernieuwen, en elke HTTP client en bibliotheek ondersteunt het out of the box Wanneer je beide kanten bestuurt en de verbinding versleuteld is, is Basic auth een volkomen redelijke keuze die al dertig jaar werkt.
De zwakke punten komen naar voren op het moment dat je buiten dat vak stapt Omdat de inloggegevens op elk verzoek worden verzonden, legt een enkele gelekte logregel of een proxy die headers registreert deze permanent bloot, en als je deze draait, betekent dit dat je deze overal tegelijk moet veranderen. Het heeft geen concept van reikwijdte, dus een basisreferentie is alles-of-niets: het kan geen alleen-lezen toegang verlenen of na een uur verlopen. En het zet bij elke oproep een echt, langlevend wachtwoord op de draad, terwijl op tokens gebaseerde schema's je in plaats daarvan een kortstondige, eng scoped inloggegevens laten uitdelen.
Voor authenticatie die naar de gebruiker is gericht, of waar u ook scopes, vervaldatum of intrekking nodig heeft, is een dragertoken het betere model, en de JWT decoder is de begeleidende tool voor het inspecteren van die Een handige vuistregel: reiken naar Basic auth voor machine-to-machine oproepen die u volledig controleert, en reiken naar tokens wanneer een derde partij, een browsersessie of een toestemmingsgrens betrokken is De onderstaande tabel somt de handel op.
| Gebruik Basic auth voor | Liever tokens voor |
|---|---|
| Server-to-server API roept u controle | Gebruikersgerichte sessies |
| Interne tools en privéregisters | Bereikte of alleen-lezen toegang |
| CI-taken en webhooks via HTTPS | Geloofsbrieven die moeten verlopen |
Veelgestelde vragen
Wat is HTTP Basic Authentication? HTTP Basic Authentication is een schema waarbij een client bij elk verzoek in de Authorization header een gebruikersnaam en wachtwoord verzendt De waarde is het woord Basic gevolgd door de base64 codering van gebruikersnaam: password Het is gedefinieerd in RFC 7617 en is de eenvoudigste manier voor een server om inloggegevens te controleren.
Hoe wordt de Basic auth header gebouwd? Sluit je aan bij de gebruikersnaam en het wachtwoord met een enkele dubbele punt om gebruikersnaam te vormen: wachtwoord, codeer die tekenreeks als UTF-8 bytes, base64-codeer de bytes en geef het resultaat een voorvoegsel met Basic De uiteindelijke header is Autorisatie: Basic gevolgd door dat token.
Is basisauthenticatie veilig? Alleen via HTTPS. Base64 is codering, geen codering, dus iedereen die de header kan lezen, kan het wachtwoord direct decoderen Basic auth biedt op zichzelf geen vertrouwelijkheid en moet altijd via een TLS-verbinding worden verzonden om veilig te zijn.
Kan de gebruikersnaam een dubbele punt bevatten? Nee De eerste dubbele punt scheidt de gebruikersnaam van het wachtwoord, dus een dubbele punt in de gebruikersnaam zou verkeerd worden gelezen als de grens en de inloggegevens op de verkeerde plaats splitsen Het wachtwoord kan een willekeurig aantal dubbele punten bevatten De generator waarschuwt u als de gebruikersnaam er een heeft.
Hoe decodeer ik een Basic auth-token? Neem het deel base64 na Basic, base64-decodeer het en lees het als UTF-8-tekst Het resultaat is gebruikersnaam: wachtwoord, gesplitst op de eerste dubbele punt. Plak een willekeurige Basic auth-header in de tool' s-decodeermodus om het onmiddellijk te doen.
Wat is het krul equivalent? curl - u gebruikersnaam:password https://example.com doet hetzelfde, want curl bouwt de Authorization: Basic header voor u op vanuit de - u waarde De tool toont zowel die vorm als het expliciete - H header formulier zodat u kunt kopiëren wat past.
Stuurt deze tool mijn inloggegevens ergens heen? Nee De codering en decodering worden volledig in uw browser uitgevoerd met JavaScript Uw gebruikersnaam en wachtwoord worden nooit naar een server geüpload, dus het is veilig om te gebruiken met echte, live inloggegevens.
Waarom UTF-8-codering gebruiken voor de inloggegevens? RFC 7617 beveelt UTF-8 aan, zodat niet-ASCII-gebruikersnamen en wachtwoorden consistent coderen tussen client en server Een encoder die ervan uitgaat dat ASCII letters met accenten of niet-Latijnse scripts zou beschadigen, waardoor een token ontstaat waar de server niet aan kan voldoen.
