Zo gebruik je het
- Voer de gebruikersnaam en het wachtwoord in.
- Kopieer de gegenereerde Authorization-header naar je client, of gebruik de curl-opdracht om het verzoek te testen.
- Wil je een bestaande header lezen, plak die dan bij Bestaande header decoderen; de gebruikersnaam en het wachtwoord worden dan getoond.
Zo werkt HTTP Basic-authenticatie
Basic-authenticatie is gedefinieerd in RFC 7617. Als een bron beveiligd is, antwoordt de server met 401 Unauthorized en een header WWW-Authenticate: Basic realm="...". De client voegt vervolgens gebruikersnaam en wachtwoord samen met een dubbele punt ertussen, codeert het resultaat als Base64 en stuurt het met elk verzoek mee:
Authorization: Basic base64(username ":" password)
# Voorbeeld uit RFC 7617: gebruiker "Aladdin", wachtwoord "open sesame"
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==Browsers handelen deze uitwisseling zelf af en tonen een inlogvenster, terwijl scripts en API-clients de header meestal al met het eerste verzoek meesturen, zonder op de challenge te wachten. Omdat de dubbele punt de twee waarden scheidt, mag de gebruikersnaam er geen bevatten; het wachtwoord wel. Een server kan charset="UTF-8" aan zijn challenge toevoegen om aan te geven dat inloggegevens met niet-ASCII-tekens in UTF-8 worden verwacht.
Base64 is geen versleuteling
De header ziet er onleesbaar uit, maar iedereen die hem ziet, kan het wachtwoord binnen enkele seconden achterhalen, met de decoder op deze pagina of met elke andere Base64-decoder. Basic-authenticatie is alleen aanvaardbaar via HTTPS, waar TLS de header onderweg versleutelt. Houd er ook rekening mee dat:
- de inloggegevens met elk verzoek meegaan, zodat één enkel verzoek via gewoon HTTP ze al blootgeeft;
- proxy's, load balancers en debugtools de header
Authorizationkunnen loggen, tenzij ze zijn ingesteld om dat niet te doen; - browsers ingevoerde inloggegevens onthouden totdat ze worden afgesloten, en er geen standaardmanier is om uit te loggen.
Voor publieke API's zijn intrekbare API-tokens of OAuth een betere keuze. Basic-authenticatie blijft een redelijke optie voor interne tools, stagingomgevingen en verbindingen tussen servers via TLS.
De header vanuit code versturen
# curl bouwt de header zelf op
curl -u 'user:password' https://api.example.com/
// JavaScript fetch (btoa werkt alleen met Latin-1-tekens)
fetch(url, { headers: { Authorization: 'Basic ' + btoa('user:password') } })
# Python requests
requests.get(url, auth=('user', 'password'))Zet inloggegevens niet in de URL, zoals in https://user:password@host/. RFC 3986 raadt die vorm af, hij belandt in de browsergeschiedenis en in serverlogs, en moderne browsers beperken het gebruik ervan.
Veelgestelde vragen
Hoe decodeer ik een Basic Auth-header?
Plak de header bij Bestaande header decoderen en de gebruikersnaam en het wachtwoord verschijnen meteen. Elke Base64-decoder geeft hetzelfde resultaat, en precies daarom mag de header alleen via HTTPS worden verstuurd.
Mag het wachtwoord een dubbele punt bevatten?
Ja. De server splitst de gedecodeerde waarde bij de eerste dubbele punt, dus alles daarna hoort bij het wachtwoord. De gebruikersnaam mag echter geen dubbele punt bevatten.
Is HTTP Basic-authenticatie veilig?
Via HTTPS en met een sterk, uniek wachtwoord zijn de inloggegevens onderweg beschermd, maar ze worden met elk verzoek meegestuurd en kunnen niet verlopen zoals een token. Gebruik het nooit via gewoon HTTP.
Waarom mislukt het inloggen bij wachtwoorden met accenten of niet-Latijnse tekens?
charset="UTF-8" opgeven; zonder die vermelding gaan oudere servers soms uit van ISO-8859-1 en vergelijken ze andere bytes.Wordt mijn wachtwoord ergens naartoe gestuurd?
Nee. De header wordt door JavaScript in je browser opgebouwd en er wordt niets verzonden. Gebruik toch testgegevens als je een gegenereerde curl-opdracht met anderen deelt.